Yes that is essentially right.

I don't know about Audacious, but for any specific configs that are important to you, you just need to identify them and make sure they are in your backups.

I tend to do things at a more granular level on my own machines. Instead of even my whole home directory, I run different scripts that reflect how I organize my own work and files, and they do not all store backups on the same machine.

Some backups I consider "live" in the sense that if my main drive is not avaliable I need to have the backup already running without the need to restore - for example my personal electronic library and knowledge base, and task managers. So those are synched and verified regularly, then periodically saved to optical media as well.

At the system level, I backup /etc and some /var paths, plus my /root which always includes the system backup scripts themselves plus admin and maintenance notes for the specific machines. And anything else that I consider worth keeping. These are generally more valuable for reference in setting up a new or replacement machine than as a restore from backup snapshot. Unless you are restoring to an identical hardware platform you are always better off installing the OS fresh then restoring equivalent function, not necessarily bit for bit copies.

For other users I mostly keep the home directories and and anything they bring to my attention such as email and web servers.

rsync is the main tool that allows me to do all these things.

I guess the point is that just like security, backups are really a process, not a program, and as such they take a little thought and management.

I agree with you completely. I do support open source and free software projects as well as purchasing software when it makes sense. Not everyone has the desire or the budget to consider commercial software. Some people decide to only use free or open source software. The best thing about Linux and GNU are that they offer more choices for all of us.

For years I've been cloning one disk to another. It takes about 20 minutes, just one program to run, no scripts to write, no thought required. The backups made this way have served me well in the event of HD crashes or in case I need to retrieve a file I messed up. The backups boot right up, no problem. It gets the job done. Nothing could be simpler.

I find it very helpful to create boot disks or additional boot partitions ahead of time for backup and recovery. There are a lot of choices for what you put on a boot disk or boot partition. Usually the idea is to make it boot fast and have the software you need for restore and recovery. You can also create scripts to perform the steps that are customized to your specific configuration.

There are Linux distros such as Puppy that are designed to be used for boot discs. They are a great resource if you don't want to make a custom boot disk but still want the tools for partitioning, restoring files and reinstalling boot loaders.

To restore a file backup to a completely empty hard disk you usually have to do these things.

1. Boot an OS (install or recovery disk / partition)
2. Partition the hard disk
3. Restore or install MBR (often done by partitioning software)
4. Restore files including OS and boot loader
5. Change boot configuration if hardware has changed (disk controllers)
6. Reinstall boot loader (because file locations have changed)

Here are some helpful boot disks that you can create ahead of time. They can be partitions, disks, thumb drives, network bootable images or any other bootable media. If you have a lot of machines to maintain then having a central network boot server may work better than boot disks.

1. Grub boot disk including partition boot menu entries
2. Linux standalone boot disk with simple GUI and utilities
3. Install boot disk for your Linux distro

I often put a web browser and files that are not part of the distro on the boot disks so that they are easy to reinstall. The biggest key to fast recovery is to prepare and then test what you prepare. You can make very general purpose boot disks or tailor them to make recovery easier on specific computers. A few of both types works well for me.

If you just restore the files for your Linux OS you can temporarily boot using a grub boot disk. Then use the live OS to reinstall grub. As someone else mentioned, sometimes it's easier to just reinstall the OS and restore the files on top. The downside is that the OS files are copied twice and any OS files that you deleted will be present again.

You can also use two different backup and recovery methods so that if one fails, the other may still work. Software isn't perfect and sometimes unexpected problems happen during backup or restore. It is very important that you test your backup and recovery methods before you rely on them. Nothing is worse than finding out your backup is useless at the moment that you really need it.

That is a good strategy if it works for you. Everyone's use cases are different.

It is sometimes difficult to remember all the reasons that we do things a certain way at any given time! But it also occurs to me that an important aspect of my own strategy is that it provides easy incremental access to my backups for various reasons, something not provided by compressed snapshots.

After partitioning the new drive, would something as simple as this give me a bootable backup exactly the same as the original drive, without overwriting the partition and boot data, where /dev/sda is the source drive and /dev/sdb the destination?

Note that I am using the "archive" option.

No, I don't think you can use it on the devices (/dev/sdx), you would use it on the mounted filesystems (/,/home,/var, etc...).

So if you have a drive or partition dedicated to the backup, call it /dev/sdb1, and you want to archive the entire root filesystem (/) then it would be something like this (adjusted for your devices and paths):

Note that this would not make /dev/sdb[x] bootable, you would need to use dd to copy the boot sectors to a file or run your boot installer separately on the backup drive.

Think of it like this: rsync is a file transfer protocol, not a bit image or clone protocol. This last point is really the distinction applicable here - if you want a clone of the drive, rsync is not the tool. If you want filesystem backups, rsync is the tool.

How about this?

rsync honors .cvsignore files, and you can use exclude list to limit what is copied, as astrogeek mentioned not everything should be copied over. If you copy over network use bwlimit option to avoid network saturation.

Unfortunately, no. Using "rsync" copies just the files and not the partition table, master boot record nor partition boot sector. Also, the positions of the copied bootloader files will not be the same as the original files. Even if you did copy the boot sectors they would refer to incorrect positions on the disk. The bootloader would have to be reinstalled to make the copy bootable.

One strategy that would work is to create a separate small boot partition for your bootloader files. Then use "dd" to copy that small partition and the MBR. You can then copy all the other OS files using "rsync".

You can copy the MBR and boot partition into a file, and then restore the file to a hard disk. That will only result in a bootable loader if the disk size, sector size and disk controller have not changed. The worst case is that you would have to reinstall the bootloader.

If you happen to use LILO, the kernel and initrd files also have to be in the small boot partition because LILO refers to ALL files by position and not using the filesystem. Grub loads an initial image (of grub) by position and then uses the filesystem to access other files including the kernel and initrd.

The boot process works like this.

BIOS-->MBR-->PBS-->GRUB-(fs)->Kernel/Initrd-(fs)->init-task

The BIOS firmware loads only the first (MBR) sector of a hard disk and then runs the software from that sector. The "standard" MBR software usually loads the Partition Boot Sector of the "active" primary partition. Each of the four possible primary partitions has a PBS (the first partition sector). The Partition Boot Sector usually contains software specific to the boot loader. The software in the PBS usually locates the first boot loader file by the disk (sector) position. In some cases (GRUB/LILO) it is also possible to install the boot loader software to the MBR. The first boot loader file either contains the entire boot loader or part of it. After the boot loader has loaded itself and the kernel/initrd, the remainder of the files are accessed using the filesystems (fs) of the kernel.

In the case of GRUB, the kernel/initrd are loaded using the filesystems of GRUB. GRUB has its own software to locate partitions and support filesystems. The only unsupported filesystem is NTFS. GRUB uses the BIOS firmware to perform disk I/O, so it is limited to accessing the disks detected by the BIOS firmware. GRUB2 supports modules that can access other kinds of disks (RAID and encrypted, etc.).

When the boot loader software is installed to the MBR then the boot process works like this.

BIOS-->MBR-->GRUB-(fs)->Kernel/Initrd-(fs)->init-task

Notice that the Partition Boot Sector is not required. GRUB can still chain to the PBS of a partition if you make the appropriate GRUB menu entry.

If you have UEFI it works like this.

UEFI-FW-(fat)->GRUB-(fs)->Kernel/Initrd-(fs)->init-task

The advantage to UEFI firmware is that it understands FAT filesystems and can load GRUB from the EFI System Partition even when the position of GRUB has changed. Although I showed "fat" in the diagram it is a little more restrictive than that. The "fat" access is limited to an EFI System Partition (including one in a CD/DVD EFI FAT boot image). For UEFI you can actually restore the GRUB files using "rsync" and still be able to boot. GRUB uses the EFI firmware to perform disk I/O, so it is limited to accessing the disks detected by the EFI firmware. GRUB cannot access files in a CD/DVD EFI FAT boot image, but GRUB can access other ISO files on the CD/DVD.

LILO works a bit differently than GRUB because it loads ALL files using the disk (sector) positions. Moving any files referred to in the LILO configuration file may cause the system to no longer boot. You pretty much have to reinstall LILO after restoring/changing any of the LILO, kernel or initrd files.

BIOS-->MBR-->LILO-->Kernel/Initrd-(fs)->init-task

ELILO works nothing like LILO and uses the filesystem support in the UEFI firmware to load files. Unlike GRUB, that means the kernel and initrd files must also be in the EFI system partition for ELILO. Since EFI only supports loading files from a "fat" EFI System Partition that is all ELILO supports. I am not sure if ELILO can load the kernel/initrd from a CD/DVD EFI FAT boot image.

UEFI-FW-(fat)->ELILO-(fat)->Kernel/Initrd-(fs)->init-task

When you install your boot loader to the PBS, make sure that your partitioning software or some other program has put the "standard" MBR software on the disk. Otherwise the disk will not boot. The advantage to the "standard" MBR software is that you can choose the boot loader that always starts first by setting the "active" partition. When you install a boot loader directly to the MBR then you must install a different boot loader (or the standard MBR software) to change which boot loader always starts first.

Most Linux distros install the boot loader to the MBR (that does not follow the PC boot standard). I suspect the reason is because it makes installation simpler and also allows booting from a logical partition in an extended partition (that also does not follow the PC boot standard). I point this out, not to bash Linux, but to say that installing GRUB to the PBS may be better for booting multipe operating systems. Windows does follow the PC boot standard, but does not give you any choice to keep existing MBR software or the choice of "active" boot partition. Both Linux and Windows installation could do better to support multiple operating systems.

That's why I'm thinking I would reinstall the OS on a new drive, then use rsync to copy the 101 preference settings such as audio equalizer settings, added fonts, use the 12-hour clock, as well as apps, things like that which don't live in the home directory.

You can't be booted to the OS that you are restoring. Some files will be in use and "rsync" will not be able to replace them. That is also true when backing up the OS. It is better to boot some other OS to backup and restore the files. There is software designed to back up an OS that is booted, but I don't think "rsync" can do that.

You will also have to be careful which configuration files you replace. Some of them are indirectly related. For example, files that control device name assignment have to agree with other files that start networking and mount filesystems. If you have deleted any configuration files then installing the OS may create them again. Having those configuration files present again may cause problems.

To avoid problems you should install an operating system that is as close as possible to the version that you will restore using "rsync". The best approach would be to reinstall just GRUB from a boot disk and then restore ALL the OS and configuration files from your backup. It is only the GRUB installation that relies on the position of the GRUB image file on the disk. Separating "/home" from the rest of the OS backup should be fine. For example, back up everything except "/home" as the OS backup.

GRUB should continue to work as long as you are careful to not change or replace the GRUB image file. To be safe you should really not change or replace any of the GRUB files after reinstalling GRUB except perhaps the "grub.cfg" file.

One thing that I like about GRUB legacy is that I can reinstall GRUB legacy using a grub command line. It is only necessary to restore the GRUB legacy files, boot a GRUB CD and then type two commands to reinstall GRUB. The current GRUB 2 requires an OS and some other software to install GRUB. Of course, you can make or use a Linux boot disk for that. The commands to install GRUB 2 are as simple as for GRUB legacy.

It helps to have an empty hard disk (or disks) to test out your backup and recovery method. Also, work with a copy of your real OS disk and disconnect your real OS disk while you experiment. Another way to do that is using virtual machine software like VirtualBox to experiment using virtual disks. The size of the disks will be smaller, but the same methods should work. I use virtual machines a lot to test scripts that might break the OS if they have an error. It is also helpful to make sure that ISO images can boot and have the necessary programs before you burn a CD/DVD.

Why files in use cannot be replaced? Why files in use cannot be backed up? You mean database files?

Good point, thanks for that. I could keep the rsync script on a thumb drive and boot up with a Knoppix CD.

rsnapshot
Something I learned after using tar, rsync, etc is that if you don't take the time to make backups automated, you won't be doing them as often as you should or wish you had.

rsnapshot is basically rsync automated with cron, using incremental backups using hard links to reduce space usage.
If for a home computer, have it run once weekly or daily to a separate HDD.

I have it running on my webserver on my VPS. It's been a absolute livesaver on multiple occasions when I trash a database or delete a crucial config file.
I just look two hourly backups ago and retrieve it. Not to mention my stress of "upgrading" has gone way down. Database corruption or file corruption? Restore