From owner-freebsd-questions@FreeBSD.ORG Sat May 26 21:44:33 2007 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB11316A41F for ; Sat, 26 May 2007 21:44:33 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 77B4013C44B for ; Sat, 26 May 2007 21:44:33 +0000 (UTC) (envelope-from nomadlogic@gmail.com) Received: by py-out-1112.google.com with SMTP id a29so2115220pyi for ; Sat, 26 May 2007 14:44:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PL0/HF9X8xPxF+lhXVfJjpzjH+AOoUP9YiIjncXFIkExGS8/bh/JKvlP9lQrdOq9UzecNmIsGjSJkYJoAbkEqezz5I9HBDZ0UKW47V4/5ZM2O8ryeOygRtKtmsN4/N3tD7YZZMZuYIO3B00zDiJwqElgsVe5jl4LBx9sYa4eYB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XF5ytzX2M7Vmq7RCcqRVmm+4PanaT7YnQA5iQPbSEwpfqm4pukrVQJP8XwYkkV7B4YjONGsjOwf5E3P9lRW+lTynI39rXQ5HVeAJONkEydzkGzYRiM8U0EpUR9/D46LpSI+H5Qg43R/xp1IBBKgg83Hcrr8YNJC/Cm5pQIeN1bc= Received: by 10.65.183.7 with SMTP id k7mr8128826qbp.1180215872809; Sat, 26 May 2007 14:44:32 -0700 (PDT) Received: by 10.65.147.14 with HTTP; Sat, 26 May 2007 14:44:32 -0700 (PDT) Message-ID: <57d710000705261444j48c515b6o4666ac2f168f7725@mail.gmail.com> Date: Sat, 26 May 2007 14:44:32 -0700 From: "pete wright" To: "Svein Halvor Halvorsen" In-Reply-To: <465898D5.7080607@lvor.halvorsen.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Cc: Roland Smith , questions@freebsd.org Subject: Re: Restore UFS snapshot X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2007 21:44:33 -0000 On 5/26/07, Svein Halvor Halvorsen 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