[sf-lug] My final comment on "Does anyone have a good backup strategy for Ubuntu 7.04 (Feisty)?"

[Michael Paoli]

Quoting RBV <GoodWriter2548 at earthlink.net>:

> Having initiated this thread, at this point I'll end my participation with
> one final observation.  That is that the word "backup" seems to have at
> least two different meanings, depending on who is using it and in what
> context.
> 
> Some, such as I, think in terms of backing up a *disc*.  Others think in
> terms of backing up *files*.  Therein is an important conceptual divide.
> The division is exacerbated, I think, by whether one is running a dual-boot
> Windows / Linux system or not.

That's "too simple" a view. :-)  Look at backup more generally.
"Backup" is making reliable backup copies of the data and essential
metadata such that one can restore, as desired, from essential file(s),
any and/or all files, up to and including complete bare metal recovery
to a system which may not be exceedingly similar (e.g. different disk
sizes/configuration, and similar, but potentially slightly different
hardware in other regards).  "Backup" also often includes off-site
coverage/storage/rotation, periodic testing (at least enough to
statistically validate the backups and the backup strategy), and
generally includes enough tracking of media and indexes to determine in
sufficient detail what's available on what backups, and where those
backups (and specific media volumes) are located.

There are file based backups (backup the files on a filesystem) and
image based backups (backup a disk, partition, LUN, device, etc., as may
be appropriate).  "disc" as you call it, is just one type of image backup.

> (there's that word again) must develop and employ two separate backup
> strategies: one for Windows disks (good) and one for Linux files (perhaps
> less good).

Naw, ... can be exactly one strategy:
image backup
or a single strategy that uses multiple methods (or not), e.g.:
script/program which backs up the relevant data in the appropriate
manner, e.g. ... this may not be my latest version, but:
http://www.rawbw.com/~mp/perl/backup,etc.tar.gz
... mostly a fairly nice wrapper program, which among other things, uses
an appropriate method to backup each filesystem based on filesystem type
(e.g. ext[23] and reiserfs use a file based method, NTFS (yeck) uses an
image based method).  Note also that NTFS is particularly yecky - one has
to be quite careful about where and how one lays it back down again if one
is using an image based method (e.g. one can't simply slap the NTFS image back
on a different location of an identically sized partition on a hard drive
and expect it to work).

> That is to say that Linux's file-based backup strategy may be most useful
> for Linux-only computers.  Having said that, I'll note that all of the
In general, OS x isn't going to handle file-based backup for OS y, though
there are some limited exceptions (e.g. LINUX can read many other filesystem
types, but it may not be able to backup all their data (e.g. NTFS "shortcuts"
and ACLs, all vFAT file attributes, etc.; there are also programs to allow
Microsoft Operating systems to access ext[23] filesystems, etc.).  In general,
though, often OS x can handle an image based backup of OS y's filesystems -
provided OS y's filesystems are "cold" (down, or mounted readonly) when
they're backed up by OS x.

> various discussions about Linux backup I've located -- including the one I
> started on this mailing list -- immediately acquire discussions if not
> disagreements about what files, exactly, can and cannot be safely
> incorporated into the list of backed up files.

There are various schools of thought along the "backup everything" and
"don't backup all that redundant stuff you already have elsewhere and
could easily restore anyway" lines of reasoning/argument.

> As such, my research has convinced me that Linux could very much benefit
> from a user-friendly, robust tool or mechanism for backing up and restoring
> ("cloning") disks.  Until then, any future upgrades to my Linux partition
> will be guided if not constrained by the need to remain compatible with
> Norton Ghost.  Caveat upgrader, as it were...

Very careful use of sfdisk and use of dd can cover that very well.  It's not
all that horribly complex.  There are probably ample tools that can well
cover much of that functionality (at least some possibilities have been
mentioned along this "thread").  I'll also state the foreign (non-LINUX)
filesystems on LINUX does make matters more complex, and sure, there's
stuff (and lots of information) to help with that, but asking one OS to
cover the filesystems of another is in general a bit of a stretch.  Some of
that's quite well covered, but there generally isn't much in the way of
guarantees (e.g. proprietary vendor y changes their proprietary filesystem
such that LINUX doesn't understand it, and makes it such that even image
backup/restore of the filesystem/partition is problematic, then that's rather
a problem for most any operating system other than that from proprietary
vendor y (okay, so it's a pain from proprietary vendor y too, but at least
theoretically it should work there ... and if not, one gets to blame
proprietary vendor y).

Although backup may be conceptually fairly simple, when it gets down to
implementation details - especially getting it (quite) right, it can be
rather to quite complex.  E.g. some things tend to be rather to quite
complex to get "just right": backing up "live" filesystems the "right"
way (transactions and coherent state, anyone?  how about backing up a large
file that's in quite active use and changes faster than one can read it
end-to-end?), efficiently backup up large
environments (exactly how do we track it, and do we need a 3,827th copy of
that identical same file from our 534 systems where it's not changed in well
over 2 years).  If backup were simple, it wouldn't take books of over 700
pages to provide a good working overview of the topic.
references:
http://www.oreilly.com/catalog/unixbr/index.html
http://www.oreilly.com/catalog/9780596102463/index.html