On 5/26/07, Svein Halvor Halvorsen <[EMAIL PROTECTED]> wrote:
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

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.


Pete Wright
NYC's *BSD User Group
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to