6 ms·

I make snapshots every hour for 24 hours, every day for 7 days, every week for 4 weeks and every month for three months. This keeps the number of snapshots reas

I make snapshots every hour for 24 hours, every day for 7 days, every week for 4 weeks and every month for three months. This keeps the number of snapshots reasonable while keeping most stuff around should you accidentally delete or overwrite it. I can see a good argument for more fine grained snapshots (e.g. every few minutes) but I think I'd limit that to directories (and thus FSes) known to have frequent updates. I sometimes blow away all snapshots if I have a big clear out or rewrite of data, or else that stuff sticks around for months.

throw0101a 5y ago
> I can see a good argument for more fine grained snapshots (e.g. every few minutes) but I think I'd limit that to directories (and thus FSes) known to have frequent updates. Fun fact, the ZFS send-receive functionality was born with snapshots being created every few minutes in mind: > ZFS send and receive wasn’t considered until late in the development cycle. The idea came to me in 2005. ZFS was nearing integration, and I was spending a few months working in Sun’s new office in Beijing, China. The network link between Beijing and Menlo Park was low-bandwidth and high-latency, and our NFS-based source code manager was painful to use. I needed a way to quickly ship incremental changes to a workspace across the Pacific. A POSIX-based utility (like rsync) would at best have to traverse all the files and directories to find the few that were modified since a specific date, and at worst it would compare the files on each side, incurring many high-latency round trips. I realized that the block pointers in ZFS already have all the information we need: the birth time allows us to quickly and precisely find the blocks that are changed since a given snapshot. It was easiest to implement ZFS send at the DMU layer, just below the ZPL. This allows the semantically-important changes to be transferred exactly, without any special code to handle features like NFSv4 style ACLs, case-insensitivity, and extended attributes. Storage-specific settings, like compression and RAID type, can be different on the sending and receiving sides. What began as a workaround for a crappy network link has become one of the pillars of ZFS, and the foundation of several remote replication products, including the one at Delphix. * https://www.delphix.com/blog/delphix-engineering/zfs-10-year-anniversary https://www.delphix.com/blog/delphix-engineering/zfs-10-year...
- ptomato 5y ago
  It remains a _delightfully_ straightforward way to do backups; I do incremental zfs send with hourly snapshots to my local NAS and also to an rsync.net ZFS account (https://www.rsync.net/products/zfsintro.html); https://www.rsync.net/products/zfsintro.html); it's incredibly resource un-intensive relative to your traditional scan-everything backup methods and I can trivially mount a past snapshot for browsing or spot restore or just do zfs send on the whole thing for catastrophic recovery.
  - throw0101a 5y ago
    As an added bonus, with (Open)ZFS encryption, you can send the 'raw' encrypted zfs send stream (over an encrypted SSH connection) to a destination where the file system is encrypted and where the zfs receive command does not have to decrypt it to save things. That is, the remote destination does not need to have the key/passphrase to the file system to have an (encrypted) copy of the data. If your production server goes down, you can restore the encrypted file system without the encryption key, and only when you try to mount the restored ZFS file system will you be prompted for the key/passphrase. > This means that you can use ZFS replication to back up your data to an untrusted location, without concerns about your private data being read. With raw send, your data is replicated without ever being decrypted—and without the backup target ever being able to decrypt it at all. This means you can replicate your offsite backups to a friend's house or at a commercial service like rsync.net or zfs.rent without compromising your privacy, even if the service (or friend) is itself compromised. * https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/ https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-...
    - cyberpunk 5y ago
      Do you happen to know if rsync.net supports this?
      - throw0101a 5y ago
        They support zfs send-recv and snapshots: * https://www.rsync.net/products/zfsintro.html https://www.rsync.net/products/zfsintro.html * https://www.rsync.net/resources/howto/snapshots.html https://www.rsync.net/resources/howto/snapshots.html Whether their ZFS implementation supports OpenZFS encryption is something you'll have to e-mail them about. They have an HN account: * https://news.ycombinator.com/user?id=rsync https://news.ycombinator.com/user?id=rsync Edit: Yes, it seems that they do: * https://news.ycombinator.com/item?id=26506263 https://news.ycombinator.com/item?id=26506263
Siecje 5y ago
Can you take snapshots more often than hourly? For example can you take a snapshot every 15 minutes?
- ptomato 5y ago
  Yup; you could do every minute with no real problems if you like. I believe you start to run into performance issues with high (1000+) snapshot counts, and then mostly when actually doing snapshot operations, so you'd want to have something to trim snapshots so you only keep your minutely snapshots for an hour and so forth.
SkyMarshal 5y ago
Out of curiosity, what do you use to automate deleting of old snapshots? I’m aware of zfs-prune-snapshots, but what’s the best way to automate it (or something like it)? Cron job, or something else? (For anyone wondering, https://github.com/bahamas10/zfs-prune-snapshots https://github.com/bahamas10/zfs-prune-snapshots)
- Alexqw85 5y ago
  I use zfsnap.[1] It's been forever since I've worked on it (hence why it's now "archived" on GitHub), but it's stable for my use and I use it on all ZFS systems I manage. [1] https://github.com/zfsnap/zfsnap https://github.com/zfsnap/zfsnap
- ncrmro 5y ago
  Checkout sandoid
- rodgerd 5y ago
  sanoid/syncoid.

throw0101a 5y ago

> I can see a good argument for more fine grained snapshots (e.g. every few minutes) but I think I'd limit that to directories (and thus FSes) known to have frequent updates. Fun fact, the ZFS send-receive functionality was born with snapshots being created every few minutes in mind: > ZFS send and receive wasn’t considered until late in the development cycle. The idea came to me in 2005. ZFS was nearing integration, and I was spending a few months working in Sun’s new office in Beijing, China. The network link between Beijing and Menlo Park was low-bandwidth and high-latency, and our NFS-based source code manager was painful to use. I needed a way to quickly ship incremental changes to a workspace across the Pacific. A POSIX-based utility (like rsync) would at best have to traverse all the files and directories to find the few that were modified since a specific date, and at worst it would compare the files on each side, incurring many high-latency round trips. I realized that the block pointers in ZFS already have all the information we need: the birth time allows us to quickly and precisely find the blocks that are changed since a given snapshot. It was easiest to implement ZFS send at the DMU layer, just below the ZPL. This allows the semantically-important changes to be transferred exactly, without any special code to handle features like NFSv4 style ACLs, case-insensitivity, and extended attributes. Storage-specific settings, like compression and RAID type, can be different on the sending and receiving sides. What began as a workaround for a crappy network link has become one of the pillars of ZFS, and the foundation of several remote replication products, including the one at Delphix. * https://www.delphix.com/blog/delphix-engineering/zfs-10-year-anniversary https://www.delphix.com/blog/delphix-engineering/zfs-10-year...

ptomato 5y ago
It remains a _delightfully_ straightforward way to do backups; I do incremental zfs send with hourly snapshots to my local NAS and also to an rsync.net ZFS account (https://www.rsync.net/products/zfsintro.html); https://www.rsync.net/products/zfsintro.html); it's incredibly resource un-intensive relative to your traditional scan-everything backup methods and I can trivially mount a past snapshot for browsing or spot restore or just do zfs send on the whole thing for catastrophic recovery.
- throw0101a 5y ago
  As an added bonus, with (Open)ZFS encryption, you can send the 'raw' encrypted zfs send stream (over an encrypted SSH connection) to a destination where the file system is encrypted and where the zfs receive command does not have to decrypt it to save things. That is, the remote destination does not need to have the key/passphrase to the file system to have an (encrypted) copy of the data. If your production server goes down, you can restore the encrypted file system without the encryption key, and only when you try to mount the restored ZFS file system will you be prompted for the key/passphrase. > This means that you can use ZFS replication to back up your data to an untrusted location, without concerns about your private data being read. With raw send, your data is replicated without ever being decrypted—and without the backup target ever being able to decrypt it at all. This means you can replicate your offsite backups to a friend's house or at a commercial service like rsync.net or zfs.rent without compromising your privacy, even if the service (or friend) is itself compromised. * https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/ https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-...
  - cyberpunk 5y ago
    Do you happen to know if rsync.net supports this?
    - throw0101a 5y ago
      They support zfs send-recv and snapshots: * https://www.rsync.net/products/zfsintro.html https://www.rsync.net/products/zfsintro.html * https://www.rsync.net/resources/howto/snapshots.html https://www.rsync.net/resources/howto/snapshots.html Whether their ZFS implementation supports OpenZFS encryption is something you'll have to e-mail them about. They have an HN account: * https://news.ycombinator.com/user?id=rsync https://news.ycombinator.com/user?id=rsync Edit: Yes, it seems that they do: * https://news.ycombinator.com/item?id=26506263 https://news.ycombinator.com/item?id=26506263

Siecje 5y ago

Can you take snapshots more often than hourly? For example can you take a snapshot every 15 minutes?

ptomato 5y ago
Yup; you could do every minute with no real problems if you like. I believe you start to run into performance issues with high (1000+) snapshot counts, and then mostly when actually doing snapshot operations, so you'd want to have something to trim snapshots so you only keep your minutely snapshots for an hour and so forth.

SkyMarshal 5y ago

Out of curiosity, what do you use to automate deleting of old snapshots? I’m aware of zfs-prune-snapshots, but what’s the best way to automate it (or something like it)? Cron job, or something else? (For anyone wondering, https://github.com/bahamas10/zfs-prune-snapshots https://github.com/bahamas10/zfs-prune-snapshots)

Alexqw85 5y ago
I use zfsnap.[1] It's been forever since I've worked on it (hence why it's now "archived" on GitHub), but it's stable for my use and I use it on all ZFS systems I manage. [1] https://github.com/zfsnap/zfsnap https://github.com/zfsnap/zfsnap
ncrmro 5y ago
Checkout sandoid
rodgerd 5y ago
sanoid/syncoid.