ZFS how to make a zfs backup?

I want to make a backup of my desktop FreeBSD box (and later my servers)
but first my desktop for testing and learning. So far reading here and there i found:
Code:
# zfs snapshot zroot/desktop@backup
# zfs send zroot/desktop@backup > /backup-desktop.zfs

This generate a .zfs file with the backup of zroot pool.

In other place I read:
Code:
# zfs snapshot -r  zroot/desktop@backup
That generates a recursive snapshot of the pool.

The questions...
  1. Is it better to use the -r option for doing the snapshot?
  2. How do I restore the snapshot from the .zfs file?
pd: I want to learn this because some time ago I lost data from my desktop
machine, running scrub won't work, the error was critical and I lost
many data.
 
Hi.

If you want to keep the "backup" in the same machine/drive you could simple take snapshots and manage them, there is no need at all to write them to a file.

Now, if you want to rollback the entire snapshot you should use the zfs rollback feature. When you want to simple get "something" from the snapshot, you can access them through the .zfs (really hidden) directory located at the root filesystem of the related snapshot.

So, a snapshot of zdata/home have that folder located at /home/.zfs. You would just need to copy what you desire to where you want.

There are tools to help you to manage that. I use sysutils/zap but there are others.

You can find more information in the WIKI.
 
Hi.

If you want to keep the "backup" in the same machine/drive you could simple take snapshots and manage them, there is no need at all to write them to a file.

Now, if you want to rollback the entire snapshot you should use the zfs rollback feature. When you want to simple get "something" from the snapshot, you can access them through the .zfs (really hidden) directory located at the root filesystem of the related snapshot.

So, a snapshot of zdata/home have that folder located at /home/.zfs. You would just need to copy what you desire to where you want.

There are tools to help you to manage that. I use sysutils/zap but there are others.

You can find more information in the WIKI.

Thanks, for now yes, the backup/restore its in one machine, but in the future i want to make backup of diferents servers and manage the
backups stored in files
 
If you want to keep the "backup" in the same machine/drive you could simple take snapshots and manage them, there is no need at all to write them to a file.

Just your friendly reminder that storing data on the same machine with snapshots is not a backup. Pretty sure everyone posting here knows that but useful to make it clear for anyone reading this thread. If you reboot your machine and it comes up with a faulted pool for some reason you've lost the lot. Of course it's still a great idea to keep snapshots on the local machine, as it makes restoring previous versions of files stupidly easy.

Regarding the -r option, say you have the following file system layout

Code:
# FS -> MOUNTPOINT
zroot -> /
zroot/home -> /home
zroot/home/me -> /home/me
zroot/stuff -> stuff

If you send the zroot/home dataset, you will get a copy of just that file system. The data in most subfolders of /home will be there, but nothing from /home/me, because that's a separate dataset. If you use -R it will also send child datasets, so the backup will contain the data from zroot/home and zroot/home/me. If you use the -R option when sending the root dataset (zroot in this case), you effectively get a backup of the entire pool because it will send the root dataset and all children. Note that you'll need to create a matching snapshot of all datasets using the zfs snapshot -r command, and then create a full replication stream of that snapshot with the zfs send -R command.

Personally I prefer to snapshot and send the datasets individually as I find it easier to manage but that's probably just me.

As for backing up ZFS to a file. In a way it's useful as you're not relying on a single file system (i.e. a bug in ZFS is less likely to take out your live data and backup). However, the issue is that ZFS is a stickler for data integrity and has checksums covering every last bit. When you come to receive a dataset from a backup file, if one bit is bad the receive will likely fail. This is why a lot of people prefer to run ZFS of their backup system so they are sending from one ZFS pool to another. If the send is successful then you know the backup system has a bit-for-bit copy of the data. If anything happens to the backup then that should be reported by ZFS (as long as you're doing regular scrubs like you should). If the backup pool is healthy you know you have a perfect backup of the data that you can restore from. A single file containing an entire dataset or even pool is a bit of an unknown.
 
Also noteworthy is that if you rely on external backups then you need to ensure that your environment has enough free space, because you can't simply restore single files. The process is basically to add the entire external backup to your system (it'll be added as a snapshot) and from there on you can then proceed with the rollback. As such you need the free space to store the backup.
 
Just your friendly reminder that storing data on the same machine with snapshots is not a backup. Pretty sure everyone posting here knows that but useful to make it clear for anyone reading this thread. If you reboot your machine and it comes up with a faulted pool for some reason you've lost the lot. Of course it's still a great idea to keep snapshots on the local machine, as it makes restoring previous versions of files stupidly easy.

Regarding the -r option, say you have the following file system layout

Code:
# FS -> MOUNTPOINT
zroot -> /
zroot/home -> /home
zroot/home/me -> /home/me
zroot/stuff -> stuff

If you send the zroot/home dataset, you will get a copy of just that file system. The data in most subfolders of /home will be there, but nothing from /home/me, because that's a separate dataset. If you use -R it will also send child datasets, so the backup will contain the data from zroot/home and zroot/home/me. If you use the -R option when sending the root dataset (zroot in this case), you effectively get a backup of the entire pool because it will send the root dataset and all children. Note that you'll need to create a matching snapshot of all datasets using the zfs snapshot -r command, and then create a full replication stream of that snapshot with the zfs send -R command.

Personally I prefer to snapshot and send the datasets individually as I find it easier to manage but that's probably just me.

As for backing up ZFS to a file. In a way it's useful as you're not relying on a single file system (i.e. a bug in ZFS is less likely to take out your live data and backup). However, the issue is that ZFS is a stickler for data integrity and has checksums covering every last bit. When you come to receive a dataset from a backup file, if one bit is bad the receive will likely fail. This is why a lot of people prefer to run ZFS of their backup system so they are sending from one ZFS pool to another. If the send is successful then you know the backup system has a bit-for-bit copy of the data. If anything happens to the backup then that should be reported by ZFS (as long as you're doing regular scrubs like you should). If the backup pool is healthy you know you have a perfect backup of the data that you can restore from. A single file containing an entire dataset or even pool is a bit of an unknown.

A really useful explication, thanks, I got a lot to learn
probably I adopt the 2 methods, and the file in a external machine of course, and the snapshot -r will be the choosen
 
Also noteworthy is that if you rely on external backups then you need to ensure that your environment has enough free space, because you can't simply restore single files. The process is basically to add the entire external backup to your system (it'll be added as a snapshot) and from there on you can then proceed with the rollback. As such you need the free space to store the backup.

yes, i'll keep it in mind when i do the backups
 
The way I kinda handle it at this time is that when I want to backup something, I just backup the following:

/boot/loader.conf
/boot/kernel/kernel
/etc
/usr/local/etc
/home/*/ negating the caches
/var/root/ negating the same caches
and now poudriere's packages repository...

that's pretty much all you need, and depending on your home folder, can save you a lot of trouble... I guess I'm still using Tar on ZFS, which can seem retarded, but I don't have tons of hard drives... though I've plenty of free online storage space...
 
Last edited by a moderator:
Before you start even thinking about *HOW* to do a backup, you need to think about what you are trying to guard against.
  • A software bug (they do exist!) which makes your ZFS file system become corrupted?
  • A hardware failure of one or two sectors on your one and only disk drive?
  • A complete failure of your one and only disk drive?
  • If you have multiple disk drives in the same computer, the correlated failure of two or more drives (partial or complete failure)?
  • Some event that completely destroys your computer (by "computer", I mean the sheet metal box that contains the disk drives), like a house fire? But that leaves other objects in the house intact (like the backup disk you keep in the basement)?
  • An event that destroys your whole house?
  • An event that destroys your whole house and a large area (so an off-side backup stored in a nearby place, for example your office or a friend's house is also destroyed)?
  • TEOTWAWKI?
Once you tell us what threats you want to guard against, we can start discussing how to do backup.

As usual, an anecdote: I used to work for a very large computer and computer services company. They used to manage a large data center, with lots of computers and storage, which was located in the World Trade Center in NYC. Because the customer was an important financial company, they had a second backup data center, with a complete second set of computers and storage, and good network connection. The backup data center was located in the other tower of the World Trade Center. :(
 
Back
Top