napp-it ZFS Storage, User Manual

16. Data Snapshots, Versioning and Backup

If you care about your data, you do backups. If you really care about your data, you do multiple backups  

like tapes that you rotate on a daily or weekly base for a data history. If your data was deleted or modified 

by accident or intention (virus, staff) you have a chance to regain original data from a former backup.

While you always need a backup for a real disaster like fire or a thief, this concept has three weak points. 

The first is that the number of backups is mostly limited due to limited resources.

The second is, that access to a backup means mostly a restore that is at least inconvenient.

The third is, that you often cannot trust the backup, because it usually has no checksum verification and 

no repair option on problems. Mostly you or the admin discover this when you need the backup - too late..

Data versioning/ secure backup

For the data versioning problem with regular user access to former states, you can save several versions of a file 
like report-2015.doc, report-2015v2.doc or report-2015-this is the latest.doc.  

Another option is a mechanism like Apple Timemachine, where you copy/sync dataversions to a another disk 
on a regular base like once a day. While this work it is annoying because of the delay when you must copy or 
restore huge data.  

Another option is Windows shadow copies on a Windows server ( https://en.wikipedia.org/wiki/Shadow_Copy ). 
This is a block level snapshot mechanism of the whole volume.  The result is a versioning filesystem. If you do 
daily snaps, you can browse/ restore the data with Windows „Previous Versions“. 

The problem remains, that you should not do too many snaps. I also had a problem with Windows VSS snaps in 
the past that they were lost after a system crash with a fress OS install. Main problem: you cannot really trust 
NTFS filesysystems (not always consistent like a CopyOnWrite filesystem) and no checksums (no verified data, 
no autorepair). This may be different in future with ReFS but currently this is not a comparable option to ZFS.

ZFS snapshots

ZFS snapshots are far better than the former solutions. ZFS is a CopyOnWrite filesystem where all modified 
datablocks are written newly while the former datablocks can be overwritten after a succesfull write.
A ZFS snapshot means that the former datablocks are blocked and cannot be re-used unless the snap is deleted. 
This requires only to keep some datapointers and can be done without delay and no initial space consumpti-
on. Even ten-thousands of snaps can be hold without any problem (Okay as the former state blocks capacity, 
sometimes the pool is full). As this is done on ZFS storage, checksum verification, scrubbing and autorepair is 
working - does not matter how old a snap is - ideal for long term storage and archives with regular scrubs.
As this is managed by the ZFS pool itself, you are not in danger too loose them when you move a pool. You can 
also trust these snaps absolutely. An admin can destoy a snap but cannot modify data as a snap is readonly.
The best is, this is transparent to a user. You can access ZFS snaps on Solaris via „Windows Previous Versions“ 
with all ACL or AD permissions intact even from a Backup. With a snapshot rule like take a snap every 15 Min-
keep 4, every hour-keep 24, every week-keep 4, every months- keep 24 you can go back two years on a filer.
 
Snapshots > Mass delete  allows to destroy snaps based on name or age. On a valid Pro or Dev edition, you can 
keep on snap per filesysten per day/week/month or mass destroy in the background (required for many snaps) 
.

ZFS backup

While you can backup data from a ZFS storage to any system, ZFS offers remote and ultrafast incremential 
replication based on snaps where only modified datablocks are transferred with ZFS security and their own 
snapshot history. In my own setups, I use two main backup systems in my serverroom where I replicate data 
based on even or uneven days and a third backup system in another building for important data and a snapshot 
history that covers at least 90 days (daily snaps)