ZFS Scheduled Snapshots Advice Request

[sonoracomm]

Hello,

We have been successfully running OmniOS + Napp-IT Pro for a long time. Our two storage servers (primary/fast and secondary/backup) are 'in production' and I am loath to make any changes that might result in any problems.

As I am quite inexperienced with ZFS scheduled snapshots, I have not implemented scheduled snapshots out of fear. However, I'm pretty sure I'm not taking advantage of a key benefit of OmniOS + Napp-IT Pro. I feel our current configuration is reliable, working well and reasonably secure, but extra resilience is never a bad thing, right?

Do I want to implement ZFS scheduled snapshots? Are there down-sides I should consider?

What might a ZFS scheduled snapshot implementation look like, considering we are somewhat risk-averse?

What about a simple scheduled snap job that just takes a daily snap and keeps only a few snapshots? I imagine a simple snap job would be less risky/problematic than a complicated job with lots of history?

Also, since we use nested ZFS filesystems, should I just snapshot the top-level ZFS filesystem? Should I snapshot the top level only? Or should I snapshot all the ZFS filesystems individually?

Any comments about scheduled snapshots are welcome. Thanks in advance.

G

p.s. My personal experience with 'snapshot hell' has been with older XenServer clusters, not with OmniOS/ZFS, but I will tell you that I tend to use snapshots sparingly and with manual oversight. I don't let VHD snapshot chains get very long.

 

[gea]

Yes, you should do snapshots as this is your best at all protection against dataloss or ransomware. Unlike other snapshot mechanism, ZFS snapshots are based on Copy on Write and just avoids a reuse of the former datablocks after a modification. This means a snap is created without delay, without initial space consumption, without performance or stability concerns even with 10000 snaps. You can create snaps for a single filesystem or recursive for nested ones.

A good snap history may consist of several autosnap jobs ex (depend on needs)
- create a snap every 15 minutes, keep 4 (4 snaps for last hour)
- create a snap every hour, keep 24 (24 snaps for last day)
..
- create a snap every month, keep 12 (12 snaps for last year)

On your backup server you can additionally preserve replication snaps with napp-it v21.x
based on the replication job, ex hours:48,days:32,months:12,years:2

Means: a snap per hour for last 48 hours, a snap per day for last 32 days,
a snap per month for last 12 months, a snap per year for last 2 years

You can also simply set, keep last n snaps or snaps newer n days.

Easiest method to access snaps: Windows "previous versions". You can also rollback a filesystem or create a clone from a filesystem (a writeable filesystem)

Space consumption of all snaps sums up only from modified datablocks. 10000 snaps without data modification do not need space.

 

[sonoracomm]

Wow, thank you so much for your VERY useful reply Gunter! I appreciate it very much.

So, to start, I configured three (recursive) autosnap jobs, one for each pool. I chose the "8;12;16" (thrice daily) schedule and a relatively short "keep 12" retention policy (to start).

Everything seems to be working perfectly.

BTW, I love the (related) "replication" feature of Napp-IT Pro. We have been using that as a backup method for a long time now and it is completely trouble free, fast and easy. The replication feature solved a (somewhat) unique backup problem I had in a very efficient way!

Thank you again,

G