Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Aug 2015 16:21:35 +0100
From:      Matthew Seaman <matthew@freebsd.org>
To:        freebsd-questions@freebsd.org
Subject:   Re: *Caution: Threadjack !!!!* Backup strategies
Message-ID:  <55E07C7F.80102@freebsd.org>
In-Reply-To: <55E06B61.7040305@hiwaay.net>
References:  <CEAD84AD-341A-4FB9-A3A1-D0D5A550AFFD@lafn.org> <55E047DC.40800@qeng-ho.org> <CAE63ME6mDXpyB7tuRvOr3sDL532fR-BGOD1swY1GoWXXxaAm=w@mail.gmail.com> <55E06B61.7040305@hiwaay.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8xOefK21v1H4opjX3HXsQ2ao6h338l5nS
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 08/28/15 15:07, William A. Mahaffey III wrote:
> Warren's (fabulously lucid) page brings up a question for me. For years=

> I have used a 'pull' strategy for across-the-LAN backups, w/ my 'backup=

> servers' using tar or rsync to access data for backup on NFS-mounted (o=
r
> automounted) directories that I want backed up. This all happens
> automatically overnight under cron. I am usually *not* backing up syste=
m
> files, but rather user data, although I have recently started backing u=
p
> system stuff as well. Warren's page consistently illustrates a 'push'-e=
d
> backup, & involves system files. I am *dead* serious about automated
> backups, no possibility of forgetting to do it that way, but I always
> thought that trying to backup 'live' system files was a bad idea
> (right/wrong ?). There doesn't seem to be a way to do a 'push' backup
> w/o messing with live system files. I guess I am asking about 'best
> practices' for backups, & the wisdom/validity of backing up 'live'
> system files. Sorry for rambling, but the question(s) popped up for me
> while reading Warren's web page. Any input appreciated. Have a nice day=

> & weekend :-).

Push vs pull strategies are a matter of taste.  With a pull strategy,
almost all the configuration is in one place and the backup server can
control resource usage -- so it's preferable if you've got a large
number of machines to back up.  Push is usually a bit simpler to script,
plus it's the only viable way of backing up to eg. a cloud service.

True, you cannot guarantee a coherent backup from a live filesystem.
Your choices are either to unmount the filesystem (or otherwise render
it quiescent) or else use some form of snap-shotting.

Snapshotting is generally the preferable option, since it avoids
disrupting the system too much while the backup is happening.  The
built-in native backup mechanisms support this: for UFS, dump(8) has the
-L flag (except with soft-updates+journalling), and for ZFS, zfs send
only works on snapshots.

Of course you can always create snapshots manually, mount them somewhere
and then use whatever tools of your choice to backup the snapshot.  This
is how I use tarsnap(1).

	Cheers,

	Matthew




--8xOefK21v1H4opjX3HXsQ2ao6h338l5nS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJV4Hx/AAoJEABRPxDgqeTnwHUP/jE1xJ4fLRcih7Xw+U7d+Upg
go60EixLhgbNl+DP3lz4g0KUcLgnB0ApY/tdKYzTMfhvUh6Cz8YjF66MJ7nQDeD5
5KamD5f5Y/nWZue/Iin1wBV3dksFyJ46YcnNsCHgaykoD6P+2AW+FeuVv8oIVON+
sU1IR6vQLaiUvY/Sc8E+qFZBh7sEld0qHDm/+uuT+7E9bmEtqujv1FJgEUnIOjjD
Y1pVkHo04pFksNUFdthLjajAAtyriCrztUNEl53P48zxOzt20oKevh1k7TAn3H0u
HymR7WQB2aYWLA5abBrWGb2kKjg6X/eScVk1usHAhBchzhiC2Pv6FJZMwWP5clLh
bAFIWRSyDfXqBrfvUzNhQJgDLHdOrJfxXg0RZ8qCJNrjkJyxvpk/Djnss7547iNb
mK4MQKSj1xc5SS6p/d42YrNurEOudVaKXL59OomMrMBkw+llIayB7+EZK0x1P9xt
wC9Qm4fi9uvt5hdErIfj/H+BF8P3BAQjQEDOjE3vu82TKUYgbPJZLCpyA6ijaH4X
CAOLZZ/egIN8yuC0mXeQNzaVQSXgosiJMiiV/A5RGsTkdvidYWfE6g6Rc64hdNuj
hzMrZAQwlAxJtl5dGx9D75BbEs6Ce/OWmnpaecxfKpLMr5p7noqdYlAEW3AyleEQ
wFUAgABuwkeXJ1nH9+E8
=TM40
-----END PGP SIGNATURE-----

--8xOefK21v1H4opjX3HXsQ2ao6h338l5nS--



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