Le 7 janv. 10 à 12:09, Thomas Løcke a écrit :

Hey all,


Hi,

My current backup system consists of a rsync/tarball combination, where rsync syncs the X directories to a remote server via SSH. When rsync is done, a tarball containing all the files and directories is created on the backup server.

The result is a backup server where there's a ~/latest/ directory containing a clone of the backed up directories/files, and a ~/ tarballs/ directory containing 14 tarballs, one for each day going 14 days back.

This has worked well for many years. I can get to the data at any given day, as long as I don't need to go more than 14 days back.

What's bad about this solution is the massive amounts of wasted space, because the same files exists in a lot of tarballs.

So I thought: How about using ZFS snapshots instead of tarballs?

On the surface it looked like the perfect match: Run rsync, and when done, take a ZFS snapshot.


It is, and if you turn on compression, it is better than perfect ;-)
And with dedup, it will be even better.

But when I started messing around with it, I quickly discovered that recovering lost files where a bit more tricky than with my current system. If I need to recover a file from 10 days back, I just grab the 10 day old tarball and restore the file from that. All the remaining tarballs remain as is. If I do the same with a ZFS snapshot, I'd have to destroy all the snapshots done between the latest and the 10 day old one, meaning all changes made since that day is lost.

This is obviously not so good.

Is there a way to revert to an earlier snapshot, without having to destroy all the snapshots between now and then? Or will I have to first copy the ~/latest/ directory to another fs, restore from the snapshot, grab the file and then copy ~/latest/ back again and take a new snapshot?

Man, is this even making any kind of sense? LOL

Is anybody using ZFS snapshots as part of a backup solution, and if so, how do you handle restoring lost files, without losing a lot of valuable data?


you don't have to destroy anything: you can access the old snapshots in the .zfs/snapshots directories.

[r...@hal ~]6 ls /data/backup/marvin/.zfs/snapshot/
2009-11-08_21h45 2009-11-23_00h07 2009-12-06_02h41 2009-12-18_03h43 2009-12-30_01h17 2009-11-09_21h51 2009-11-24_22h10 2009-12-07_02h48 2009-12-19_02h55 2009-12-31_01h18 2009-11-11_01h21 2009-11-26_02h35 2009-12-08_02h09 2009-12-20_02h45 2010-01-01_01h16 2009-11-12_22h56 2009-11-27_02h51 2009-12-09_02h26 2009-12-21_02h44 2010-01-02_01h16 2009-11-13_22h11 2009-11-28_02h17 2009-12-10_01h59 2009-12-22_02h32 2010-01-03_01h19 2009-11-14_22h05 2009-11-29_02h20 2009-12-11_02h33 2009-12-23_02h16 2010-01-04_01h14 2009-11-15_21h54 2009-11-30_02h36 2009-12-12_03h04 2009-12-24_02h14 2010-01-05_01h22 2009-11-16_21h43 2009-12-01_03h36 2009-12-13_02h40 2009-12-25_01h15 2010-01-06_01h16 2009-11-17_22h05 2009-12-02_05h05 2009-12-14_01h55 2009-12-26_01h15 2010-01-07_01h16
2009-11-19_01h31  2009-12-03_02h53  2009-12-15_02h59  2009-12-27_01h18
2009-11-21_00h19  2009-12-04_17h05  2009-12-16_05h09  2009-12-28_01h18
2009-11-22_00h34  2009-12-05_02h24  2009-12-17_02h12  2009-12-29_01h12
[r...@hal ~]7 ls /data/backup/marvin/.zfs/snapshot/2009-11-29_02h20/
Module.symvers  etc             lib             opt             usr
bin             home            lib64           root            var
boot            initrd          mnt             sbin
[r...@hal ~]8 zfs list -o space,compression,ratio data/backup/marvin
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD COMPRESS RATIO data/backup/marvin 4.87T 41.9G 28.8G 13.1G 0 0 gzip-4 7.18x

Gaëtan

--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

Attachment: PGP.sig
Description: Ceci est une signature électronique PGP

_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to