5 ms·

>>Backup consistency? Free and vastly simplified. >Snapshots are not backups. If you pretend they are you will loose all your data. The good thing about snaps

>>Backup consistency? Free and vastly simplified. >Snapshots are not backups. If you pretend they are you will loose all your data. The good thing about snapshots it that you can use them as a consistent base for your backup: If you naively copy files over from a running system, you'll get inconsistent data, but if you copy it over from a snapshot, it'll work without taking the system down.

tscs37 9y ago
That is fairly obvious, a lot of systems provide snapshot functionality irrelevant of the file system. If you still need snapshots, there are several methods without needing CoW Filesystems, notably LVM and dattobd (both of which I have utilized in the past) Also keep in mind that a pure snapshot from a running system will behave like a system that just crashed, a half written file won't complete the write magically because you have snapshot. If you don't tell postgresql that you're doing snapshots or backups, both will likely corrupt data, doesn't give you anything in that case. Same for desktop systems. You make a snapshot of the runnign system and suddenly the browser only finds corrupted settings because a write wasn't complete until after the snapshot.
- Dylan16807 9y ago
  If postgresql corrupts your data upon sudden halt you have far bigger problems to worry about. And as far as I know most software acts responsibly with files, either writing out the new version to a temp file or using sqlite. Both of which are atomic-snapshot-safe.
  - tscs37 9y ago
    You might still loose partial datasets (especially when the database is not 100% perfectly constrained) and not all software handles such sudden halts perfectly. Making a snapshot of any working dataset of any software without the data corrupting or loosing parts of the working set is a pipedream.
X86BSD 9y ago
Yeah I somewhat understand the phrase "snapshots are not backups". But what really constitutes a "backup" ? Because I argue snapshots are backups. I snapshot a dataset. And use ZFS send/recv to a remote ZFS server of the dataset snapshot. Is that not a backup? I argue it is. If the original dataset is completely trashed I simply send/recv again the remote snapshot of that dataset back to the primary server. Plus you can update with incremental send/recv as well. I simply don't need tapes. I suppose for archival purposes one might want a tape copy somewhere. But even tapes are problematic. They degrade, get chewed up, etc. There are fewer variables with digital data for me personally.

tscs37 9y ago

That is fairly obvious, a lot of systems provide snapshot functionality irrelevant of the file system. If you still need snapshots, there are several methods without needing CoW Filesystems, notably LVM and dattobd (both of which I have utilized in the past) Also keep in mind that a pure snapshot from a running system will behave like a system that just crashed, a half written file won't complete the write magically because you have snapshot. If you don't tell postgresql that you're doing snapshots or backups, both will likely corrupt data, doesn't give you anything in that case. Same for desktop systems. You make a snapshot of the runnign system and suddenly the browser only finds corrupted settings because a write wasn't complete until after the snapshot.

Dylan16807 9y ago
If postgresql corrupts your data upon sudden halt you have far bigger problems to worry about. And as far as I know most software acts responsibly with files, either writing out the new version to a temp file or using sqlite. Both of which are atomic-snapshot-safe.
- tscs37 9y ago
  You might still loose partial datasets (especially when the database is not 100% perfectly constrained) and not all software handles such sudden halts perfectly. Making a snapshot of any working dataset of any software without the data corrupting or loosing parts of the working set is a pipedream.

X86BSD 9y ago

Yeah I somewhat understand the phrase "snapshots are not backups". But what really constitutes a "backup" ? Because I argue snapshots are backups. I snapshot a dataset. And use ZFS send/recv to a remote ZFS server of the dataset snapshot. Is that not a backup? I argue it is. If the original dataset is completely trashed I simply send/recv again the remote snapshot of that dataset back to the primary server. Plus you can update with incremental send/recv as well. I simply don't need tapes. I suppose for archival purposes one might want a tape copy somewhere. But even tapes are problematic. They degrade, get chewed up, etc. There are fewer variables with digital data for me personally.