[plug] re: disk backup

[Jon Miller]

Thanks James,
I'm only interested in getting a backup nightly of the system and if it
was possible to get a mirror image of the system this would be a bonus.
I just don't want to have to rebuild everything from scratch.
My choices was either do a mirror backup or backup the disk to a tape
backup unit on another server.  I'm also considering installing NDS on
the server(s) so this can be handled by our NetWare servers and the
add-ins for Linux backup.
Granted I know it's not going to be exact but at the time the backup is
operating there would not be any users on the server, just the e-mail
that would be coming in and this would be sufficient. 

I'll have a look at the archive first though.

Thanks

Jon

On Tue, 2003-07-01 at 10:04, James Devenish wrote:
> In message <1057024215.2188.1524.camel at jlmpc>
> on Tue, Jul 01, 2003 at 09:50:15AM +0800, Jon Miller wrote:
> > However, it appears to indicate that in order to do this correctly one
> > has to be in single mode.
> 
> It's always safest (to prevent corruption of the backup) to
> do it in single-user mode or with the devices unmounted.
> 
> Since dd makes an exact backup, changes to file length (e.g. log
> entries) can invalidate the backup severely. Utilities such as
> dump will not suffer this, though they may still produce a backup
> where, say, log files don't correspond to the same time of day.
> 
> Since you mentioned disk-to-disk, dd has the advantage of producing an
> exact duplicate of the original mountpoint and thus you can mount the
> backup if desired. In fact, this is an easy way to create an
> immediately-available backup boot volume (without needing RAID as such)
> in case your current disk fails.
> 
> > Is this the correct method or is there a way this can take place while
> > the server is running in regular mode?
> 
> The short answer is: it is never safe to do a backup in regular mode.
> The long answer is: it is often safe enough to do a backup in regular
> mode if you know enough.
> 
> The principal reason is:
> 
>     The backup will take time. 15min or 15hr -- whatever it is for your
>     system. It won't happen instantaneously. Thus, your backup will be
>     internally inconsistent if the disk contents are modified while the
>     backup is in progress.
> 
> Three stand-out sources of changes are:
> 
>     Operating system: your kernel may not have flushed all buffers to
>     disk when you start the backup (though you have a great chance if
>     you run `sync` in single-user mode).
> 
>     Users: they sometimes try to do stuff!
> 
>     Daemons: including network daemons, kernel logging, cron, log
>     rotation, etc.
> 
> There has been a lot of past discussion on this list regarding backups.
> Comments have included mentions of these, at least:
> 
>     Software: there are lots of backup options on generic systems
>     (including dd, tar, cpio, dump).
> 
>     Shutting down daemons: this makes sure databases are in a
>     self-consistent state (daemons don't necessarily keep the disk
>     contents valid if they are doing processing in memory), prevents
>     unexpected modifications.
> 
>     Snapshots: after syncing your disk, create a snapshot so that
>     the system can continue to be active while you do a backup from the
>     static snapshot.
> 
> There should be lots and lots of information in the PLUG mail archives
> alone.
> 
-- 
Jon Miller <jlmiller at mmtnetworks.com.au>
MMT Networks Pty Ltd