Burning mixed ownership of files to disk producing a problem?

Tim ignored_mailbox at yahoo.com.au
Thu Nov 18 18:44:11 UTC 2010


On Thu, 2010-11-18 at 11:32 -0500, William Stock wrote:
> In a small test I had no problem burning some of "my" files and some
> "root/root" files.  However, using the CD for a restore would be a
> gigantic pain in the backside.  You'd be sitting in front of your
> monitor forever.

Yes.  DVDs and CDs aren't great for lots of little files (really slow
seek speed, slow read speed), but are reasonable for large files where
the slow seek speed comes into the equation less often.  And, depending
on how you put the files on the disc, you'd have to correct all the
changed ownerships, file permissions, and SELinux contexts.  And you'd
have to do it as root to be able to access all the files you want to
backup, and the same when you restore them, later on.

My suggestion about tarring (or otherwise archiving the files), puts all
that ownership, permissions, and file context information within the
archive, where it can be restored as the files are extracted.

Though a gotcha with that, is people who backup their files, install a
new system, create a new user by making the same username but not with
the same numerical user ID, then try to restore their files.  Generally
speaking, the name is for your benefit, the filesystems go by the ID.

Backups tend to be a multi-part methodology.  Determine the files to be
backed up, copy/archive them to a container, put that container file on
some media.

Then you have almost the reverse, for the restore process.  Find the
right media, find the right archive, find the files you want, restore
them.  Have a process to check for actual, rather than apparent, success
(e.g. checksums, not just waiting for the file copy to finish).

Without a plan for all of that, you're probably going to miss something
vital, and not be able to do what you need to do.

A typical mistake is to restore *all* files from your backup, over the
top of a system, stomping over things that should be left alone (either
files that were still okay, or erasing files created between the backup
and the restoration).

I had that happen to me when my webhost fiddled with their server, and
without notifying me about anything.  Wiped my site, restored an old
backup, and the site stopped working.  I had to change all the
permissions of hundreds of files (their backup was obviously not a true
backup), identify and restore missing or subsequently modified files,
and force them to update the DNS records.  The idiots sent the record
date backwards (decremented the serial number, construed from a date),
during their restore.  And refused to see anything wrong with doing
that.  Any outside caches of the records wouldn't bother to update their
records, since the serial number didn't *increment*.  And, of course,
they had the nerve to try and deny all of that.

-- 
[tim at localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.





More information about the users mailing list