Re: Do snapshots solve all consistency problems ?
> From http://www.tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html :
> # lvcreate -L592M -s -n dbbackup /dev/ops/databases
> lvcreate -- logical volume "/dev/ops/dbbackup" successfully created
> Maybe one should donate them a paragraph about known
> pitfalls. They _are_ overly optimistic without doubt.
If you like to do things like this, you should know what might happen.
> > >From the new star man page:
> > Backups from life filesystems should be avoided.
> ... if that constraint does not keep you from making
> backups in sufficient frequency.
This is why I create backups using filesystem snapshots.
> > Be careful that all files that have been created between set-
> > ting up a snapshot and starting an incremental backup may be
> > missing from all backups unless the dumpdate=name option is
> > used.
> Interesting pitfall. I'm still learning from star.
> Such an option is on my todo list meanwhile.
This pitfall has been reported one year after Sun introduced snapshots,
so it does not seem to be obvous :-)
> > If the system that is going to be backed up is not acting as
> > a file server, it makes sense to shut down all services that
> > may result in inconsistent file states before setting up the
> > filesystem snapshot.
> Oh. You aren't as overly optimistic as i thought.
> I've read that paragraph a few days ago but did not see
> the connection to my concerns. (Probably i perceived
> "inconsistent" too much in the sense of fsck.)
I am realistic....not optimistic.
> But Joerg, it is written in your own man page.
> "result in inconsistent file states"
> that's what i mean with
> "run blindly into a standing car".
If an application creates a file with inconstent content,
the backuptility cannot help.
> Shutting down all complex services does not seem
> to be far away from a short visit at run level 0.
> The snapshot reduces the downtime substantially,
> of course.
> But there is a downtime with connection loss and all.
If you could verify that there is no service that
creates files with inconsistent content, you don't need
to shut down the services while setting up the
> If the snapshot catches me between the one write() and
> the other write() which only together form a usable
> file change ... then i'm doomed.
> About atomicity of larger filesystem changes:
> The journaled thingies _could_ be able to do so.
> I googled, stumbled over file change logs which look
> cool for everybody who wants to do incremental backups.
> No actual commit/rollback found. Not to speak of a
> standard API for that trick.
No, if an application does not write things that need to
be done atomically in a single write(2) call, journalling
does not help.
EMail:email@example.com (home) Jörg Schilling D-13353 Berlin
firstname.lastname@example.org (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily