7 ms·

Does the off-site backup also contain the write that happened 1.5 seconds ago? What about the corruption that happened just before taking the backup?

• deleted 11y ago
  [deleted]
• oconnore 11y ago
  This is a ridiculous scenario. If you have some files on your laptop that are super important, you probably shouldn't `rm -rf` them 1.5 seconds after uploading to your NAS. If you were working on that file, you shouldn't wait to save it until you are finished, or should be prepared to redo that work. Save it as you go. Anyway, if a drive fails 1.5 seconds after a write, any of the btrfs supported Raid levels (-0) will save you. If corruption happens just before a backup, no Raid level will save you, because Raid does not protect against undetected silent corruption. Btrfs may save you there, because it does computes checksums -- allowing you to detect the corruption and recover. If you really are going to immediately purge some critical data from its source location 1.5 seconds after fsyncing to your drive, you should be sending it to multiple locations and waiting for confirmation containing a valid checksum before considering the write a success.
  • rapala 11y ago
    > This is a ridiculous scenario. If you have some files on your laptop that are super important, you probably shouldn't `rm -rf` them 1.5 seconds after uploading to your NAS. There is nothing ridiculous about a hard drive breaking between backups. There are situations where loosing all data after latest backup would be, if not unrecoverable, at least extremely irritating. Having redundant drives in a laptop might not be feasible, but dedicated workstations are still used in many places. > If you really are going to immediately purge some critical data from its source location 1.5 seconds after fsyncing to your drive, you should be sending it to multiple locations and waiting for confirmation containing a valid checksum before considering the write a success. Which is exactly what ZFS/btrfs in a mirrored RAID configuration does.