*Caution: Threadjack !!!!* Backup strategies

[William A. Mahaffey III]

On 08/28/15 10:27, Matthew Seaman wrote:
> 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 (or
>> automounted) directories that I want backed up. This all happens
>> automatically overnight under cron. I am usually *not* backing up system
>> files, but rather user data, although I have recently started backing up
>> system stuff as well. Warren's page consistently illustrates a 'push'-ed
>> 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.

Can I unmount the root fs (for example) once booted ? I thought not .... 
One of the machines I am backing up is a RPiB+ running NetBSD 7.0-beta, 
serving as the time server for my LAN. It has only 1 large partition for 
root, so I get it all in my backup. Could that be unmounted 
(temporarily) for a backup ?

>
> 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.


I just checked on the RPi & the '-L' flag has been hijacked to use for 
labelling the dump, bummer !!!!


>
> 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).

Yeah, but I want automation !!!!

>
> 	Cheers,
>
> 	Matthew
>
>
>


-- 

	William A. Mahaffey III

  ----------------------------------------------------------------------

	"The M1 Garand is without doubt the finest implement of war
	 ever devised by man."
                            -- Gen. George S. Patton Jr.