I want to back up a user's home folder by making the entire content into an archive document and storing it on an external ext3 (or ext4?) hard drive. I'll want to keep all the file attributes. Is this a good command? Any particular advice? Does line 4 has any redundancies?

2 Answers
2

Your command looks fine. Are you planning on using variables for the date part? One trick - that data is going to grow and grow on you. What's your policy for how long you will keep it?

I've found for data of lesser consequence, that it's actually better to name backup files things like SUN MON TUE, and let them overwrite "next week" to control disk space a bit better an infer quickly how much backup you have online.

As to your question about restoring, it's usually something like tar xfz TARFILE.tar.gz ... but you should get in the habit of reading your tar files first with something like tar tfz TARFILE.tar.gz just so that you can understand what you're actually restoring.

If I recall, you're going to preserve your directory structure the way you're doing it - meaning the restore will create a directory called home/jimmy wherever you choose to restore it.

Don't take my or anyone's advice however; make sure you test thoroughly. The worst case is that it seems like its working but two years from now when you have a drive crash you realize it wasn't...

Thanks for the info. It's about policy and I'm still in building blocks. Seriously, my next stop is figuring out "cron" or anything that lets me HAVE a variable. (Or looking into "dump".)
–
SmandoliOct 10 '10 at 14:23

Hey.
I'm certainly no expert in this area, and I was just pinging a linux sysadmin friend's brain for advice on a backup solution this afternoon, but I might suggest rsync instead?

rsync -avuz --exclude=PATTERN /path-to-source /path-to-destination

will create an archive backup with permissions, owner attributes, and creation times intact, and compress (zip) the transfer, excluding files which match "PATTERN" ... and if you run it again to same directory, it will update (-u) only replacing files whose checksum has changed.

Alternatively, you should (as I was recommended to do) look into rsnapshot and rdiff-backup.

I made a small start in rsync -- actually grsync -- a few months ago. I will take a fresh look. I can't recall why I didn't adopt it at the time, but sometimes I merely run out of energy and time, and the trail goes cold. :-)
–
SmandoliOct 10 '10 at 14:25

heh. Understood, there's an infinite number of trails to head off in, and only so much life. But rsync -> great goodness worth the time invested. I've been using this one for a backup solution since I was a noob competent enough to google and stumble my way through entering it on a command-line. The update-ability is the key that makes rsync special, and rsnapshot works off this as well. So, instead of sending a new copy every time you backup, you're only sending the changed bits.
–
e.m.fieldsOct 11 '10 at 4:31

above ^ meaning: Less space used, and less bandwidth to update. If you "tar" entire disk to back up, it must both transmit and save this entire disk each backup. If you rsync, it only sends and saves the changed files. So, your target directory is only ever as large as your source, and your transmit is only as large as the changed bits. Rsnapshot does the same, but creates a new snapshot for each, and hardlinks the unchanged parts, so that you have a "complete" directory structure from each backed-up date
–
e.m.fieldsOct 11 '10 at 4:36