Hi there, Being a cutting-edge hipster, my new personal server is using a ZFS RAIDZ array, where my older system used UFS on a GMIRROR. This is, by and large, a joy: ZFS rocks. One issue that I'm having difficulty coming to grips with, though, is that of backup. I used to do a weekly cycle (with a two week retention) of incremental backups to an external hard drive. Dump/restore allowed this to be useful both for disaster (hardware failure) recovery and for clumsiness (file destruction) recovery. Dump/restore doesn't work for ZFS. I *think* that I'm running backups in the appropriate equivalent fashion: I take file system snapshots (both absolute == level 0) and relative (incremental), and zfs send those to files on the backup disk. I haven't tried the recovery procedure yet, but it seems that one would zfs receive the same files to snapshots, and then either grab the files scrunged or perform the snapshot->working file system upgrade process described in the manual, depending on the situation. The troubling aspect of this plan is that it would seem that grabbing just a few files would require space in the working zpool equivalent to the whole backed-up file system, for the zfs receive of the snapshot. Contrast this with restore, which had a nice interactive (or command line) mode of operation that could retrieve nominated files or directories, requiring only space for the results. Is there any similar tool that can operate on a ZFS "send" serialization? It would seem that the information must be "in" there somewhere, but I've not heard of it. Clues? How does everyone else manage this? Cheers, -- Andrew
on 22/11/2010 13:35 Andrew Reilly said the following:> The troubling aspect of this plan is that it would seem that > grabbing just a few files would require space in the working > zpool equivalent to the whole backed-up file system, for the > zfs receive of the snapshot. Contrast this with restore, which > had a nice interactive (or command line) mode of operation that > could retrieve nominated files or directories, requiring only > space for the results. Is there any similar tool that can > operate on a ZFS "send" serialization? It would seem that the > information must be "in" there somewhere, but I've not heard of > it. > > Clues? How does everyone else manage this?What I do is keep the snapshots for long enough and just retrieve the files from there. That is, snapshots - for the "clumsiness case", backups - for the disaster case. -- Andriy Gapon
On 11/22/2010 6:35 AM, Andrew Reilly wrote:> Dump/restore doesn't work for ZFS. I *think* that I'm running > backups in the appropriate equivalent fashion: I take file > system snapshots (both absolute == level 0) and relative > (incremental), and zfs send those to files on the backup disk.This is actively discouraged, there is no recovery ability when receiving zfs streams so 1 bad bit would invalidate your entire backup. The currently accepted practice is to create a ZFS file system on the backup drive and just keep sending incremental snapshots to it. As long as the backup drive and host system have a snapshot in common you can do incremental transfers. This way you only have to keep the most recent snapshot on the main system and can keep as many as you have space for on the backup drive. You also have direct access to any backed up version of every file. HTH, Jonathan
On 2010-Nov-24 11:07:23 +0100, Alexander Leidinger <Alexander@Leidinger.net> wrote:>Quoting Peter Jeremy <peterjeremy@acm.org> (from Wed, 24 Nov 2010 >06:32:07 +1100): > >> BTW, the entire export is performed at the current compression level - >> recompressing existing data. > >Are you sure the compression is done on the sending side, and not at >the receiving side? I would expect the later (as I can specify a >different compression level on an existing destination, if I remember >correctly).Sorry, that was poorly worded. The actual send stream is not compressed but the entire filesystem stream will be re-compressed on the receive side as specified by the "compression" parameter on the sending filesystem. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20101124/ecc96ed4/attachment.pgp