[K12OSN] Got to rebulid -- how to take an image for checkpointing

[Les Mikesell]

On Sat, 2006-08-26 at 23:14, Chuck Kollars wrote:

> (Background info: a "ghosting" program copies
> raw sectors without understanding anything about
> whatever OS they instantiate).
> 
> The inadequacy of a file-by-file approach is often
> a moot point because disks are so large a
> "ghosting" program is a practical necessity.
> Anything that goes through the file system, when
> faced with 80GB, can be rather slow.

That probably matters a lot if you are rolling out
hundreds of desktop clones.  For a server or two you
can go to lunch while it copies.  Also, unless you
use a copying program that understands the filesystem
it may take longer to copy the empty portions of
the drive than to do file copies of the used part.

> Linux systems can't always be treated cavalierly
> as just what's visible from `ls`.  True, Windows
> is seldom backed up simply as a large collection
> of files; but the reason is there are few really
> adequate backup programs, not because it's 
> theoretically impossible.

That's only true if you use the esoteric features
added later than the copying program - like ACLS
and the extended attributes for SElinux.  And
dump is supposed to work for these now as long
as your destination has the same filesystem type.

> So what exactly is going on?  There are several
> "problematic" areas in viewing any OS through the
> lens of its file system:
> 
> 1) "Hidden" and "system" file attributes are
> particularly problematic.  But this problem
> doesn't just affect Windows.  In Linux files whose
> name starts with a "." are conventionally not
> displayed.  Ever done a `cp` only to discover none
> of the "dot" files were copied?

That has to do with shell wildcard expansion intentionally
omitting the files using the convention.  cp copies
whatever you tell it to copy.  The GNU version of cp
as included in all linux distros includes the -a option
to recurse and copy all (normal) attributes and works
as well as tar or rsync to copy a system.

> 3) In most modern OSs there can be "metadata"
> associated with each file.  Even Linux has this
> option, which unfortunately most of its programs
> don't handle  correctly.  Have you ever backed up
> a file system that uses ACLs (Access Control
> Lists) with `tar`, restored it elsewhere, and
> wondered what happened to all your ACLs?

These are filesystem type, not just OS specific.  The
dump/restore programs for each fs type may or may not
be able to reproduce these attributes when copying to
the same type of fs.  The star program claims to copy
posix-compatible ACL's in a portable way but probably
only in versions newer than included in fedora.

> 4) Some applications (think "AD") are paranoid
> about security but don't support adequate recovery
> procedures.  Consider an application that changes
> its hashes every fifteen minutes, embeds
> timestamps in its data, and doesn't provide a way
> to resynchronize.  It's almost impossible to back
> up, not only as a collection of files but even as
> a collection of raw sectors (which is how 
> "ghosting" tools would see it).
> 
> So yes doing a naive file-by-file copy often 
> doesn't do what you want it to, especially with
> Windows. But no there's no need to postulate
> secret binary data to explain why.  

How would you describe the windows registry in a way
that makes sense to a file copy?

It doesn't matter if it is secret or documented if
the tools you have won't copy it.  Personally, I like
to keep all important data backed up in a portable format
and have scripts or procedures to put back any attributes
that don't come along.  That might involve a database
dump or a backup of parts of a system with a native backup
tool into files included in the backup run, and/or a ghost
image to be installed before the current backup files are
restored.  If you are always prepared to restore a working
machine, cloning one isn't that much of a special case,
although if you have swappable drive carriers it's hard to
beat sticking 2 identical disks in the box, booting a CD
in rescue mode and using dd.

-- 
  Les Mikesell
   les at futuresource.com