Setup backup

[capchuckprice]

Scorp's approach has a lot of merit. It is hard to get much simpler than a couple of lines typed into a shell. Especially when a system has crashed down to the point that all you have is a shell.

I also like the fact that with Scorp's approach, you get to recover individual files easily. With the (very nice, I might add) Partimage solution, you restore an entire partition, even if you only wanted one file. And, oops, you might find that while you got that one file back, you back-versioned many other files you really wanted to keep. So if, say, you backed up your whole partition last week, but deleted some critical file an hour ago, everything gets restored to where it was last week.

What scorp's simple solution does not provide "out of the box" is an incremental backup capability (ie, "backup only what changed since last time I did a backup").

That sort of backup capability is very powerful, but can add lots of complexity. This is what you find in many commercial backup solutions, and is what tends to make them both difficult to learn and complex to use.

Unfortunately, these things *don't* have to be so complex. Indeed, once you have mastered tar (gzip itself is trivial), adding a rudimentary incremental capability is really not very hard at all (hint: -u option to tar on backup, -k option on restore).

The reason they get complex with the typical GUI tool (commercial or open source) is 1) the GUI tool author assumes the user is an idiot, and 2) the GUI tool designer is frequently not trained in the art/craft/science of human factors, and really doesn't do a good job of communicating functionality. One should not assume that GUI == easy. Frequently the opposite is true.

It would be nice if someone did put together an elegant front end to the rich set of power tools available to the Linux user. A GUI that is a very simple "Do what I need" image (bootable), full, and incremental backup solution that meets the following criteria:

1. The archives can be directly manipulated in a straightforward way by the standard non-GUI power tools (tar, etc.).

2. The tool can analyze the installation and backup the "right" stuff automatically, only being told where to place the archives.

3. The tool can suggest and implement a "best practices" automated backup scheme, without input from the user (taking rational defaults, but allowing overrides [such as best time of day, frequency of full versus incremental, etc.).

Anyway, for a new Mint user but long time Unix user, that's just my $.02... Hmm, maybe I should start working on that as my open source contribution...

[scorp123]

What scorp's simple solution does not provide "out of the box" is an incremental backup capability (ie, "backup only what changed since last time I did a backup").

I agree here - my solution doesn't provide that. On purpose. As you correctly said -- feeding 'tar' with the right parameter would be easy. But experience has taught me that incremental backups --while being a time-saver when making backups-- can cost you twice that time again when you have to restore things especially if things go seriously wrong, e.g. when for some stupid reasons you don't remember anymore important files are missing from the incremental backup but some moron --maybe even yourself?-- deleted the last good full backup ... Murphy's Law: if things can go wrong they sure as hell will go wrong and you'll be the one banging his head against the table.

This has happened to me. Bad luck is a b*tch but one hell of a good teacher -- you'll never again forget the lesson.

So for me it's full backups. Yes, they take longer and yes, they use up more space than incremental backups. But unless a nuke explosion's EM pulse wipes my disks clean I am quite confident that I will get my data back somehow.

Scorp's approach has a lot of merit. ... Especially when a system has crashed down to the point that all you have is a shell.

Thanks for that. That's *exactly* the point of it. It happened often enough to me that when things seriously go wrong the shell is your very last best friend and your last and only hope. So you better know how to talk to it and how to tell it to get your data back and bring life back into this dead metal chunk of computer hardware.

Maybe I am a bit old-fashioned. That's possible.

[capchuckprice]

I agree here - my solution doesn't provide that. On purpose. As you correctly said -- feeding 'tar' with the right parameter would be easy. But experience has taught me that incremental backups --while being a time-saver when making backups-- can cost you twice that time again when you have to restore things especially if things go seriously wrong, e.g. when for some stupid reasons you don't remember anymore important files are missing from the incremental backup but some moron --maybe even yourself?-- deleted the last good full backup ... Murphy's Law: if things can go wrong they sure as hell will go wrong and you'll be the one banging his head against the table.

The most common fault I have experienced is not someone else deleting my backup files, its a corrupted backup file. There is nothing more terrifying than, in the midst of repairing a critical system, watching your tools reject your last hope.

While it violates the KISS principle, putting together a system that creates separate full and incremental backup archives, rotated over a period by a cron job (e.g., a full backup Sunday night, and incrementals through the week, saving two weeks worth of backup files), gives one a lot more safety than a single archive. Frequently modified files (probably the ones you most care about recovering) tend to end up in more than one archive (one or more of the incrementals plus the full archive).

Unfortunately, this is likely to be something the typical self-supporting Linux user (especially a newbie) is unlikely to set up. The best fall back, then, is to do the full backup regularly, verify the archive, and store the archive reliably.

Regarding reliable storage, several things are worth pointing out to newbies. CD's are not inherently reliable. Tape is susceptible to magnets, disuse and heat. Rotating disks fail. Those little flash widgets get lost.

The answer? Don't depend on a single copy of a single archive to save the day. If you use hard disk backup (which I do at home), use a basic RAID setup for reliability. Off the shelf terabyte RAID 1 (simple mirror) devices are cheap these days (that's 500GB available, replicated), and if you are the least bit handy, you can even build one yourself. (I see no need to go beyond RAID 1 for replicated backup purposes.)

CDs should be treated with utmost caution. I would recommend that if you depend on CDs for backup, you find the best available *archival* media, and that you verify the media can be read back, preferably not just on the device that created it. For backup, IMO, CDs are slow and scary.

Tape has all sorts of physical issues, but is quite reliable if handled well. Tape must be used, or else it will fail due to winding pressure on the tape reel. Thus, tape is something that does wear out faster than other media. Tape is usually the first choice for pro IT shops (cheap media, and easy to setup and leave unattended for a week or longer), and the last choice for consumers. For the home user, I recommend hard disk, RAID based backup, perhaps with critical personal files being infrequently placed on flash, CD or DVD for redundancy.

I guess the bottom line from this rambling note is that the choice of GUI/non-GUI front end is really the least of your concerns when thinking through a backup solution. Regardless of whether you are setting things up on Linux, the Mac, or Windoze, the serious thought needs to be put into the possible failure modes. Scorp123 rightly touches on one important one: "What if the system has failed down to the command prompt level?" There are others as well, perhaps even more serious, or at least compounding the crisis: "What if I can't read the backup media?", "What if the computer is completely destroyed (or lost or stolen) and I have to recover onto new hardware?", "What if I have to recover critical files via some other operating system?", etc.

Good luck!

[scorp123]

... {many words of wisdom} ...

Excellent posting!

[JAK]

So getting back to the original notion of doing a full system backup. I downloaded "remastersys" from the Romeo repo and installed it. I keep getting an error telling me it's looking for the original LinuxMint CD at the /dev/hdb when it's mounted at /media/LinuxMint 3.0 (or something like that). I tried to force the CD to mount at /dev/hdb, but then I got other errors.

What I would like to do is make an installable "backup" of my current setup. That way if something does go wrong I can reinstall LinuxMint just the way I like it configured.

Are there any other solutions like remastersys that actually work, or there some config file I can edit to have remastersys look for the original LM CD at /media/LinuxMint ?
.