On 5/26/07, Svein Halvor Halvorsen <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
