Makin' backups -- questions

Ronald F. Guilmette rfg at tristatelogic.com
Fri Jun 12 10:37:24 UTC 2020


In message <ef3ebee8-a3f1-8caf-040d-d9483afc5c15 at holgerdanske.com>, 
David Christensen <dpchrist at holgerdanske.com> wrote:

>On 2020-06-11 17:01, Ronald F. Guilmette wrote:
>> I'm re-writing my backup scripts and could use a bit of advice.
><snip>
>
>I have used rsync(1) for backup and restore of data files for many years.

So I am in good company.

>But I very much doubt that an rsync(1) copy of a live system disk is 
>going to be correct.

Oh it is "correct" alright... for some value of "correct".

This is a single user system and when I am doing backups I am generally
not otherwise actively using the system.

Of course, it *is* running a mail server, other daemons, and god only
know what else in the background (e.g. cron scripts).  So you are
essentially correct that I am making backups of moving targets.
I am fully aware of that fact and it doesn't really bother me.

Unless one is doing raid, one will not ever have a backup that is
fully current to the current microsecond.  But that's OK.  Backups
are useful, in emergencies, even if it means that you have lost all
of the work you did for, say, the past 1 day or that past 1 week.
That's still WAY better than losing all of your stuff back to the
beginning of time!

So yes, I make backups, on-the-fly, of "moving target" live filesystems.
When and if I need any one of those full partition backups, it will
containe enough good stuff so that I will be damn glad I had it,
and that's enough for me.  This is a home/work machine.  I'm not
doing anything irreplacable or mission-critical here.  I'm not JPL,
sending probes to mars.  Neither am I running a savings & loan or a
medical office here.

>Excluding anything makes me even more incredulous.

As I say, unless you are doing raid, every backup you have is something
less than up-to-the-current-microsecond.  what I have is good enough
for my purposes.

>AIUI the traditional Unix backup/ restore process is to shutdown the 
>machine, boot a live USB stick or move the source drive into another 
>computer, mount the source filesystem(s) read-only, and use dump(8) to 
>serialize each filesystem to a file.  Restoration consists of preparing 
>a target device with a partitioning scheme, boot loader(s), slice(s), 
>partition(s), and/or filesystem(s), and then using restore(8) to 
>deserialize the files into the target filesystems.  (See Clonezilla [1].)

Yea.  Exactly.  That all sounds like great fun... NOT!  (I *do* use Clonezilla
for backing up my Linux and Windoze systems, BTW, because in those cases I
routinely power them off anyway. I prefer -not- to power off my FreeBSD
server system to make backups of its drives & partitions however.  Call me
lazy.  I won't mind.

>The simplest, but least efficient, backup method I have found for system 
>drives is to copy the device raw sectors to a file with dd(1)

Too slow.

rsync allows me to just update my backup drives incrementally, which is
WAY faster.  (My server has 3TB live.  DD'ing all of that would take all
night.)

>1.  dd(1) is a lowest-common-denominator tool...

Believe me, this isn't my first rodeo, and I know what dd is and what it
does.

>2.  I use MBR partitioning, to avoid problems with the GPT backup 
>partition table when the source and target device sizes differ.

You're going to have to explain that one to me.  What are these "problems"
of what you speak?


Regards,
rfg


More information about the freebsd-questions mailing list