16 January 2008
zfs_restore: the cool way to restore from backups
Posted by aastaneh under: Uncategorized .
Most sysadmins know that ZFS natively keeps snapshots of files, which makes it perfect for an incremental-backup solution. Unfortunately, when trying to restore a lost file using ZFS, (especially remotely in this case) the process can be rather complex (EDIT: not really complex or difficult at all… its just that it could be even easier), which is a shame considering it’s usefulness.
Until today.
Using the powers of ZFS, rsync, and Bash, I have devised a solution which makes accessing and restoring backups so simple, even normal users can do it!
Let’s say I have an account on a multi-user system, and I accidentally deleted a file in my home directory:
[aastaneh@login0 ~]$ rm fftw-3.1.2.tar.gz
It’s a really important file, and I need it back right now. I call my trusty sysadmin to restore the file for me. He can either enter in a bunch of hard-to-remember esoteric commands, or do this:
[root@backups ~]# zfs_restore aastaneh
Now in ZFS File Restore Environment
Restricted Command Set: dates setdate restore [file], ls, cd [dir], exit
backupsh snapshot>
The admin is now given a custom command shell which has a simple set of commands. We use ‘dates’ first to give the listing of all the snapshots present:
backupsh snapshot> dates
20071206000201 20071209000143 20071212000103 20071216000135 20071218132440
20071207000228 20071210000134 20071213000210 20071217000054 20071219000106
20071208000251 20071211000107 20071214010339 20071218000233
The ‘20071219000106′ looks the most recent. We choose it with ’setdate’:
backupsh snapshot> setdate 20071219000106
Now we are in my home directory from yesterday. The admin has the ability to dig around in my home directory using ‘cd’ and ‘ls’.
backupsh 20071219000106> ls
. .ssh gmxtest.tgz
.. .viminfo gromacs-3.3.2
.Xauthority abinit-5.4.4 gromacs-3.3.2.tar.gz
.bash_history abinit-5.4.4.tar.gz gromacs-clean
.bash_logout abinitconfigure gromacs-configure.patch
.bash_profile configure-working grompp.out
.bashrc discrep.ieee id_rsa
.elinks discrep.reg id_rsa.pub
.forward discrep.reg-1030 mail
.lesshst fftw-3.1.2 maillog
.matlab fftw-3.1.2.tar.gz scratch
.mbox gmxtest-3.3.2.tgz
We see the lost fftw-3.1.2.tar.gz, so we restore the file with ‘restore’(which just calls rsync on the file with the right options):
backupsh 20071219000106> restore fftw-3.1.2.tar.gz
building file list ...
1 file to consider
fftw-3.1.2.tar.gz
2736360 100% 92.08MB/s 0:00:00 (xfer#1, to-check=0/1) sent 2736798 bytes received 42 bytes 5473680.00 bytes/sec
total size is 2736360 speedup is 1.0
backupsh 20071219000106> exit
(root@backups) Thu Dec 20 13:33:37
Voila! My day is saved. My file is now restored to my home directory, timestamped so that the restore process does not clobber files.
[aastaneh@login0 ~]$ ls fftw*.gz*
fftw-3.1.2.tar.gz-20071219000106
Requirements: The script must be running on a system with ZFS snapshots, probably a Solaris system. This script was written assuming a NIS install somewhere, but I can imagine working around that if NIS isn’t used on the network. Rsync was also used, but I also think another option can be used as well (scp?)
Caveats:
- If the script does not work successfully the first time, first check with the ZFS utilities to see if a mountpoint has been defined already for the user you are trying to restore. You will have to manually perform the unmount before the script will work properly.
- The restored file gets copied to ‘~user’, not to it’s respective subdirectory where the file was restored from.
- This script needs some better sanity checks to ensure that future users don’t try to traverse up the directory structure to / or something silly
Code: zfs_restore source
Leave a Reply
You must be logged in to post a comment.