Re: [gentoo-user] Back up a server in real-time

[Mick <michaelkintzios@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On Sunday 16 November 2008, Alan McKinnon wrote:
> On Sunday 16 November 2008 02:08:42 Mick wrote:
> > On Saturday 15 November 2008, Dale wrote:
> > > Mick wrote:
> > > > Without gentoo-wiki my knowledge level is rather poor (just like my
> > > > memory!)
> > > >
> > > > What would you use to back up a running server without taking it off
> > > > line?
> > >
> > > I keep mine simple, cp -auv paths/you/want/to/backup back/up/to  It has
> > > works so far.  Thought about doing a cron job but that complicates
> > > things.  :/
> >
> > Thank you all for the suggestions and for the link to the wiki!  I've got
> > some reading to do.  ;-)
> >
> > Whenever I have used tar to back up a whole OS I used it with a LiveCD.
> > This was to make sure that files and their metadata were not being
> > changed while I was tar'ing them.
> >
> > Are you saying that I can actually fire up tar/rsync and back up in real
> > time?
>
> Yes. Unix does some RealSmartThings(tm) when using files. The name is just
> a pointer to the actual file, represented by an inode. Once you have an
> inode open, it stays open until everything using it closes it. So you can
> add/delete/copy/move files by name with impunity as you then just move
> names around. Contrast this with other inferior systems, like say Windows
> for example, which has a built-in self-destruct button when you try this...

Sure, but isn't there a problem with atime mtime metadata when you carry out a 
backup in real time and then restore from it?

> > I was gravitating towards using LVM snapshot and then tar'ing that to an
> > external USB drive.
>
> This is the preferred way, as you get a consistent snapshot frozen at a
> point in time. This deals nicely with inconsistencies caused by files
> changing while you are backing up other ones.

Right, that's what I was thinking too.  What does restoring from a backed up 
snapshot involve?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]