Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Nov 2003 09:31:04 +0000
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Keith Spencer <bsd2000au@yahoo.com.au>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Can I bakup like this...?? <--user mode Reuben?
Message-ID:  <20031120093104.GA81178@happy-idiot-talk.infracaninophile.co.uk>
In-Reply-To: <20031120022835.43690.qmail@web12008.mail.yahoo.com>
References:  <20031119154354.GA39475@ei.bzerk.org> <20031120022835.43690.qmail@web12008.mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 20, 2003 at 01:28:35PM +1100, Keith Spencer wrote:
> Hi all, thanks to all replying.
> I just spent many hours finding out my bakup strategy
> was useless (didn't know what I was doing I guess)
> Now I need to do it properly.
> Ruben (and others)
> Can I do the tarring of filesystems in a cron job
> without being in single user mode?
> I just followed a mostgraveconcern tute to move to a
> larger drive and it worked well.
> Lots of tarring etc BUT...all done in single user
> mode. I imagine I cant do THAT and reboot etc etc in a
> cron job.
> I am going to try Ruben's idea and allay concerns by
> having a removable 2nd harddrive so I can do this >
> once to take a drive off site
> So comments?
> Is dump easier (for a dill like me) to use or
> whatever?

The point of dropping to single user mode when doing disk copies is
primarily to make sure that nothing is going to be writing to the
disks during the copying process.  (There's a subsidiary consideration
when copying some files owned by eg. databases, where the on-disk
state of the file does not correspond with the actual state of the
data, and you need to do a clean shutdown to get everything
synchronised, so that the database can start up again cleanly.)

If you can achieve the same effect by other means then that's just as
good.  However, on the whole, dropping to single user is going to be
the easiest and quickest way of doing this sort of thing.

The same considerations apply to doing backups, but usually dropping
to single user is not going to be feasible in that case.  The strategy
in this case is simply to do the best that you can to avoid problems:
backups should be run while the system is quiet, which usually equates
to the small hours of the morning.  In 5.x there's a new facility to
"snapshot" a filesystem, which essentially holds off all pending disk
writes in order to let a backup process complete.

Now, you can't absolutely guarrantee that your backup will contain a
completely consistent view of a file system (generally because you
cannot run the backup instantaneously).  However, most of the time an
only-slightly inconsistent view is good enough.  For this reason, and
to insure yourself against failure of your backup media you should
always aim to have multiple copies of your backups available.  Now,
you could just run two backups every night onto separate sets of
media, but that's really far too expensive, so generally people will
opt for having several sets of backup media and cycling through them.
Maybe the tape drive shredded your backup tape from last night, but
you'll still have the tape from the night before.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/vInYdtESqEQa7a0RAnpkAJ9j9rF5jyUgO8s+xqfQ/rwDZg9heQCeLwxw
T1dKIhS1dEHkE4bUDLev2v8=
=vUQv
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031120093104.GA81178>