*Caution: Threadjack !!!!* Backup strategies

[Polytropon]

On Fri, 28 Aug 2015 17:16:36 -0453.75, William A. Mahaffey III wrote:
> 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 .... 

That depends on what you consider the root file system.
It's commonly where / is mounted, carrying the SUM binaries
and all top-level mount points. This is different from
what's commonly called /boot (which can be a separate
file system, but _can_ be part of /) where the kernel
and the modules are located. The kernel is usually
placed into memory by the boot loader which also loads
modules. But what if an additional module is being loaded,
or you want to query the kernel file (not the memory copy,
but the on-disk instance)? Then /boot needs to be mounted.
As you will agree, it's even more complicated with the
common root partition.

Unmounting something is always a question of access. :-)


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

No (except you can make sure _no_ access is being made to it).
Solution: Put it into read-only mode and hope for the best
(i.e., that no program tries to write to it). If you can't,
at least use dump -L so it will work with a snapshot.



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

Go to a factory! :-)


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...