Restore UFS snapshot

[pete wright]

On 5/26/07, Svein Halvor Halvorsen <svein.h at 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