Date: Sun, 21 Feb 2010 10:22:23 -0600 From: John <john@starfire.mn.org> To: "C. P. Ghost" <cpghost@cordula.ws> Cc: Aiza <aiza21@comclark.com>, freebsd-questions@freebsd.org Subject: Re: Dump questions Message-ID: <20100221102223.D17365@starfire.mn.org> In-Reply-To: <d74eb87c1002210510r329fe0aiac68cf245eddbeda@mail.gmail.com>; from cpghost@cordula.ws on Sun, Feb 21, 2010 at 02:10:29PM %2B0100 References: <4B80ABBA.9000707@comclark.com> <20100221110358.9ec8b286.freebsd@edvax.de> <4B812C8F.40102@comclark.com> <d74eb87c1002210510r329fe0aiac68cf245eddbeda@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 21, 2010 at 02:10:29PM +0100, C. P. Ghost wrote:
> On Sun, Feb 21, 2010 at 1:52 PM, Aiza <aiza21@comclark.com> wrote:
>
> > Polytropon wrote:
> >
> >> On Sun, 21 Feb 2010 11:42:50 +0800, Aiza <aiza21@comclark.com> wrote:
> >>
> >>> 1. Using the -L flag to create a snapshot of the
> >>> live running file system.
> >>>
> >>> Does this mean that a complete copy of the file
> >>> system is written to .snap directory?
> >>>
> >>
> >> No. The snapshot, quite incorrectly explained, is a saved
> >> delta between the file system on disk at a given state, to
> >> fixate further modifications (that are not included in the
> >> dump, of course).
> >>
> >>
> > Sorry, I read your words but have no clue as what you are trying to say
> > with that statement. As i understand 'delta' to mean, the difference in file
> > system content between a point in time 'A' and 'B' some point in time later
> > in the future. Now just what is snapshot recording between point 'A' and 'B'
> > and how does that apply to what dump is going to read and write?
>
>
> A somewhat inaccurate explanation is this:
>
> When you (or dump -L) create a snapshot, the current state of the filesystem
> is "frozen" and a snapshot file is created. As soon as some process starts
> to
> modify the filesystem, the old blocks at the time of snapshot are written in
> the snapshot file and the new blocks are written in the ("current")
> filesystem.
>
> Now, when you (or dump -L) read the snapshot file, the UFS filesystem does
> some magic behind the scenes: if the snapshot file contains the blocks you
> ask for, it means that the corresponding blocks in the filesystem have
> already
> been changed. That's okay: UFS will then give you the old blocks from the
> snapshot. If the snapshot file doesn't contain the blocks you asked for, it
> means
> that those blocks were not modified in the filesystem, so UFS gives you
> those
> unmodified blocks, right from the filesystem.
>
> When the snapshot file is deleted, the filesystem will not be monitored
> anymore
> and old blocks of modified blocks will not be saved anymore.
>
> The net result is that by reading the snapshot, you get the "frozen" state
> of
> the whole filesystem, while everybody else who does read the filesystem will
> get the current state.
>
> Well, it doesn't work exactly as outlined above, but conceptually, it comes
> pretty close.
Let me just add to this thread to make sure we document the intent:
The point of such a snapshot is to give you a point-in-time consisent
view of a filesystem. On an active system, the state of the file system
may change from the time you beging the backup to the time you complete
it, meaning that if you ever have to restore, you may find "time skew"
corruption. By taking the snapshot, you at least have the "point in
time" view of the file system. That doesn't mean it will be perfect!
If there were files being updated or written at the moment the snapshot
was taken, they may be internally inconsistent - part new, part old - but
from a file system structure point of view, they will be uncorrupted.
So - you may still have to take steps to queisce users, databases,
or other applications to get everything in the file system in a known
state BEFORE you take the snapshot! But, at least, you only need to
do it for the few seconds it takes to instantiate the snapshot, and
not the whole time it would take to do the backup.
Without snapshot (to have a "pefect" backup):
Shut down all your applications and kick off all your users
If you're really paranoid, unmount the file system (so you know
it's not being accessed)
Run your dump
remount the filesystem
Restart your apps
let your users back on
You can have confidence when restoring from such a backup, but it may
be a practical impossibility!
With snapshot (and a few other "gives" to practicality)
Alert your users of when the snapshot will begin, so they can avoid
actively modifying files at the time of the snapshot
Quiesce all your applications - many databases have ways that you
can put them into extended logging mode or "write-aside" mode
to give you a guaranteed, transactionally-consistent copy
(and some just operate that way all the time), but if your applications
don't USE transactions - well, it may be best to just shut them down
for a few seconds anyway
sync;sync;sync (OK - we probably don't do that anymore - I'm an old-timer)
Start the snapshot
Let everyone go back about their business
Do your dump / backup
Release the snapshot
That should give you the same quality of backup, or pretty darn close,
with minial interruption to your users and the services you provide.
My point is, if you're simply starting the snapshot without doing
anything else, you'll be in the same state after a restore as you
would from a power failure or other system fault. If you are
comfortable picking up from such a state and moving forward, that's
fine, but if you need a more consistent state of affairs, you may
want to take a few extra steps. Power outages and systems failures
which stop filesystems cold are rare - but your snapshots and
backups will (hopefully) be frequent - and will eventually catch
your system in just about every meta state in which it could possibly
exist. If you never have to recover from them, more power to you,
but you have to consider the case in which you might actually USE
your backup.
The problem with backups is - you never really know if you can
restore the state of BUSINESS until you try it. If you've never
done a full system restore and attempted to bring up all your
applications and recover things to a known state from which you
can go forward - don't assume that you can! This is what "DR
(Disaster Recovery or Disaster Restart) simulation" is all about.
--
John Lind
john@starfire.MN.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100221102223.D17365>