Wich backup program for a slacker
 

I recently found in my prospects sbackup from sourceforge to simply backup the system under Linux.
But I also noticed it is a gnome oriented program under python.

I was wondering if it's a good backup solution for Slackware as I am running current.
Or may be there is just a command line to do it manually.
Or is there any other suggestions ??

;) NjB ;)

The answer will be rsync.

give rsnapshot a try :-) very good and easy to setup & use.

Choosing a backup solution requires defining your needs.

I will assume that you are looking to do backup of a home system.
For my home PC, which has multiple partitions with NTFS partitions for Windows as well as Slackware32 and Slackware64 partitions, I backup to an external USB hard drive.

To backup the Slackware partitions I use 'rsync -av /path/to/Slack/ /path/to/USB/drive/' in a Slackware install apart from that which I want to backup. This means that I do not have to worry about problems that arise from trying to backup a live system. ( I have also used SystemRescue CD to do this).
To backup the NTFS partitions I use 'ntfsclone --output /path/to/USB/drive/imagefile /dev/WindowsPartition'. I sometimes add the '--save-image' option to ntfsclone to reduce the space required for the backup file, but I try to avoid this as it can be useful to be able to do a loop mount of the image.

Do you mean I do it from another PC in my home local network.
Or I simply logout from my cession.

Or am I obliged to boot the PC from a system usbkey or live CD to avoid backing up a live system ?

:tisk: NjB

No, you do not NEED to boot from to another system, but it does make life easy to do so. That way you do not have to worry about excluding directories (eg /sys /proc that are only populated when the system is live) or directories where files can change (eg /var/log).

This is the point of my first sentence. You need to define your needs. Are you happy to boot to another system to avoid complexity and take the associated downtime and inconvenience penalty? If not, then the backup procedure becomes more complex.

There are very good arguments for not backing up a live running system (yes, do the backup from another OS). There is the possibility that something freshly written to the running disk (or not yet written by some application), can be missed at the last second in the backup. However that said, I've been doing live backups of my desktop machine using `rsync` for several years now, and have never had a problem doing it or restoring from a backup.
I wrote a little backup script that gets run by cron every morning. For various reasons, my script ignores /sys, /proc, /tmp, any Trash directories, and any mounted external media.

In short: I vote for rsync, regardless if you do it live or not. rsync is efficient and the command line syntax is not complicated.

Here is the command I use to backup:
Repeat for all filesystems. e.g.
Then to restore I:
-Boot from a live cd
-Mount my Slackware and backup partitions
-And run something like:
Short explanation of the rsync options:
-a = archive mode (preserves permissions and stuff)
-v = verbose
-H = preserve hard links
-x = one filesystem (don't copy files from other filesystems e.g /proc, /sys, /home, /boot, etc)
--delete = delete extra files from destination directories

@piratesmack:
Thanks for the above post. For some reason I had never found the -x option for rsync. I had a backup script that ran as a cron to backup all of the partitions except "/", then I would occasionally boot from another partition & backup "/". I've been (carefully) testing this code since I read it & today added it to the script. It is nice to know that I don't have to remember to backup my root partition.
@njb: As noted above this solution works well for me, but YMMV. You should try it.
Regards,
Bill

If you are using lvm, you can use the snapshot mechanism to ensure a consistent view of the logical volume that you are backing up. See http://www.howtoforge.com/linux_lvm_snapshots (which gives Debian-specific information on how to restore a root partion). The LVM-HOWTO also talks about lvm snapshots: http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

http://serverfault.com/questions/239...ackup-strategy has some pointers too.

+5 to that. How fast do you need to get the system back after a failure? For most home users an adequate disaster recovery plan is to buy a new computer (or fix, as required), re-install OS and apps, restore user data. A utility company's billing server needs to be back online a bit faster than that!

How much work and cash are you prepared to put into it? How much expertise do you have?

Do you want a graphical restore facility? Including being able to restore old versions of files?

Are you planning on off-site backup media?

One backup solution that wasn't mentioned was hubackup (Home User Backup) which looked promising a few years ago -- but people had difficulty restoring from it (which defeated the object!).

LVM snapshots are important if you have apps that spread coordinated data across several files such as a database that has separate files for data and indexes -- or you can stop those apps while the backup is running or use their built-in backup tools.

Personally, I use rsync + ssh to backup my data daily from multiple computers to multiple targets, both local and remote. It is a one-page script, it leaves complete logs, and in the last 6 months or so I never was unsafe for more than a couple of days. My backup is very simple, though, since I only save the data (think /home/qweasd) and a few system configuration files which I'd like to have handy if my filesystem implodes. I do not backup entire volumes because reinstalling either Slackware or Ubuntu on my home computers only takes a few hours, and that is the route I am willing to take. Your situation, of course, may be very different.

rsync + Grsync for you.

Grsync! Well heck, never knew that existed. I'll have to try it. I have a heck of a time remembering all the options...

As for backups, on my home system, I vote for rsync, a properly thought out partition strategy and a properly defined backup strategy. Do you

1. want fast recovery from HD crash?
2. want to save personal data?

With (1) you can just image the whole drive. You can save it to an bootable external USB drive to restore quickly. You can also loop mount to grab bits.
With (2), place /home on another partition, rsync it to another drive. For example, I have '/home', '/archive' and '/archive2'. All my important docs are on /archive (500 GB SATA), /home (90 GB partition on a 120GB PATA) gets copied to /archive, and /archive gets rsynced to /archive2 on an external USB drive (500 GB). That gives me 2 (3 for /home) copies of my files.

I also copy /etc in case I need those files. I don't bother with saving / as I have found it just as easy to do clean install and then 'upgradepkg --install-new' from /archive, etc. to restore the system.

If you want, you could also set up mirrored RAID. I ran a data acquisition server a while back set up with mirrored, hot-swappable SCSI-3 drives. The Oracle database was also dumped daily to a backup server that was a mirror of the first.

As its too late to make a long story short on this Sunday morning...the message here is: Just what is it that you want to back up?

The guy was nice enough to spit out the commands passed to rsync (ALT+R) ;]