4 ms·

I believe the Debian policy for reports says that for corruption you can recover from. Serious data loss would be losing your metadata and not being able to fig

I believe the Debian policy for reports says that for corruption you can recover from. Serious data loss would be losing your metadata and not being able to figure out where any of the files are, or corrupting all copies of the disk encryption key.

userbinator 3y ago
I think "corruption you can recover from" seems far too vague; you can recover from any corruption with backups.
- piperswe 3y ago
  The way I'd interpret it is that it's non-serious if fsck can repair it. Not sure if that's accurate though, just the way it sounds to me.
- viraptor 3y ago
  If you're trying to be padantic and missing forest for the trees... Sure.
- LoganDark 3y ago
  Sure, and you can recover from any hardware failure with a separate computer. In fact, you can recover from death simply by cloning yourself. What's the issue? The issue is that some people don't have the time, money, and/or willpower to invest in backups. Some people only have one volume, or one copy of each volume at least, and need to recover their data using only that one volume if something gets corrupted. That's what "corruption you can recover from" means. Using a backup is not recovering from corruption; it's replacing the corruption with the pre-corrupted data. Recovering from corruption involves actually transforming the corrupted data back into non-corrupted data.
  - remram 3y ago
    I think you're agreeing with userbinator here.
    - LoganDark 3y ago
      Not really. They're arguing that backups count as recovering from corruption, where my argument is that backups don't count because the only thing you're doing is discarding the corruption, not recovering from it. You're basically throwing the corruption out and getting your data back from somewhere else. So you recover your data, but not from the corruption. You recover it from a backup. Similar, but not the same thing.
      - tremon 3y ago
        In this case, I would say that backups are not relevant protection. In order to restore something from backup, you would first need to know that a restore from backup is needed, and secondly you need to know what the last-known good copy is. This is a silent data corruption bug (data is written at the wrong offset, IIUC) with no known method to detect the error condition except to compare the resulting data with a known-good copy. The next backup run will happily accept the corrupted file contents into the backup vault, and unless someone happens to stumble upon the corrupted data, the last-known good copy will eventually be rotated out.

userbinator 3y ago

I think "corruption you can recover from" seems far too vague; you can recover from any corruption with backups.

piperswe 3y ago
The way I'd interpret it is that it's non-serious if fsck can repair it. Not sure if that's accurate though, just the way it sounds to me.
viraptor 3y ago
If you're trying to be padantic and missing forest for the trees... Sure.
LoganDark 3y ago
Sure, and you can recover from any hardware failure with a separate computer. In fact, you can recover from death simply by cloning yourself. What's the issue? The issue is that some people don't have the time, money, and/or willpower to invest in backups. Some people only have one volume, or one copy of each volume at least, and need to recover their data using only that one volume if something gets corrupted. That's what "corruption you can recover from" means. Using a backup is not recovering from corruption; it's replacing the corruption with the pre-corrupted data. Recovering from corruption involves actually transforming the corrupted data back into non-corrupted data.
- remram 3y ago
  I think you're agreeing with userbinator here.
  - LoganDark 3y ago
    Not really. They're arguing that backups count as recovering from corruption, where my argument is that backups don't count because the only thing you're doing is discarding the corruption, not recovering from it. You're basically throwing the corruption out and getting your data back from somewhere else. So you recover your data, but not from the corruption. You recover it from a backup. Similar, but not the same thing.
    - tremon 3y ago
      In this case, I would say that backups are not relevant protection. In order to restore something from backup, you would first need to know that a restore from backup is needed, and secondly you need to know what the last-known good copy is. This is a silent data corruption bug (data is written at the wrong offset, IIUC) with no known method to detect the error condition except to compare the resulting data with a known-good copy. The next backup run will happily accept the corrupted file contents into the backup vault, and unless someone happens to stumble upon the corrupted data, the last-known good copy will eventually be rotated out.