Date: Sat, 26 May 2007 14:44:32 -0700 From: "pete wright" <nomadlogic@gmail.com> To: "Svein Halvor Halvorsen" <svein.h@lvor.halvorsen.cc> Cc: Roland Smith <rsmith@xs4all.nl>, questions@freebsd.org Subject: Re: Restore UFS snapshot Message-ID: <57d710000705261444j48c515b6o4666ac2f168f7725@mail.gmail.com> In-Reply-To: <465898D5.7080607@lvor.halvorsen.cc> References: <465864F4.7060500@lvor.halvorsen.cc> <20070526180336.GB34660@slackbox.xs4all.nl> <465884E3.5000500@lvor.halvorsen.cc> <20070526194342.GA37130@slackbox.xs4all.nl> <465898D5.7080607@lvor.halvorsen.cc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/26/07, Svein Halvor Halvorsen <svein.h@lvor.halvorsen.cc> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Roland Smith wrote: > >>> You can mount the snapshot, and then copy the files back to the original fs. > >>> Note that cp can preserve flags, but not ACLs AFAIK. > >> Yes, I know that this is possible. However, it's a lot of work. > > > > Huh? > > > > Suppose you did 'mksnap_ffs /usr /usr/.snap/20070526' > > > > Then all you have to is something like: > > > > # mdconfig -a -t vnode -f /usr/.snap/20070526 -u 0 > > # mount /dev/md0 /mnt/snapshot > > # cd /usr > > # tar cf - /mnt/snapshot/* |tar xpf - > > # umount /mnt/snapshot > > # mdconfig -d -u 0 > > > > How much easier could it be? You could easily create a script for this > > as well. > > Let me clarify: It is a lot of work for the computer, for the hdd. > > > >> There should be some straightforward way of rolling back to a > >> snapshot, since the files and all the file system structure are > >> already there. Also, there might not be room on the disk for it. > > > > Snapshots take up room as well. > > But the snapshot is already made. > > Again, let me clarify: > > > At some point in time, my file system is filled with random* bits. I > then make a snapshot. > > - From now on, all bits** that I flip will be take up an extra bit of > space. Then, after changing lots of bits, I decide I wanted the old > data back, as the file system was before I started to flip bits. > > Now, I could either: > > (a) Flip alot more bits, by making copies of the snapshotted bits > over some free area of the disk, or > > (b) Undo all the bit flipping I have done, since I made the snapshot. > > > In (a) I will have two copies of all the bits that has changed since > the original snapshot, while in (b) I am back to where i were before > the snapshot. > > Does this make any sense? Have I not understood this correctly? > > hmm...i'm still a little confused as to where you are going. there are three main way's i've used snapshot's in large (~1PB) environments, two of which are applicable to you i believe: 1) dump(8) file system after snapshot, not only for backup/DR purposes - but to insure that you have a valid disk image of your critical filesystem before doing something risky (installworld etc.). in this case dump to a scratch volume 2) restore(8) dumped filesystem image if something bad happens, otherwise let tmpwatch clean remove the dump at a later date. while this may require more space, it does give you a reasonable amount of certainty that the disk image is valid and consistent (esp. pertinent for frequently modified data sets - let's say LDAP databases). now, here is an easy way to go - that should work for static dataset's: an installworld goes bad and /usr/bin is borked: $ tar cvpf - /usr/bin/.snap/ | (cd /usr/bin; tar xvpf -) or something similar. you could use rsync, but that would give you uneeded overhead IMHO. -p -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57d710000705261444j48c515b6o4666ac2f168f7725>