Ask Your Question

rsync on root vs package reinstall

asked 2016-02-11 00:52:10 -0500

zug234zwang gravatar image

updated 2016-02-11 20:43:18 -0500

This is a followup of what I believe to be three open issues re the following query on this forum:

rsync boot disk dirs to exclude

Because of my inexperience, one of my replies on that query became mis-positioned, which caused that webpage to be confusing. I'm hoping for responses from several people on this followup query. Issues:

(1) Suppose that:

a. My boot drive is (device = sda) and my docking station houses a backup hard drive (device = sdc).

b. I have already used a recent version of Fedora22 Live to install the (full) Fedora22 on (device = sdc), making sdc bootable.

c. I want to maintain sdc as a full backup (i.e. a functional "clone") in case sda goes bad, totally relying on periodic rsync's of the sda-root against sdc to keep sdc current.

d. I want to be able to both boot the backup from the docker (position sdc) or replace the original boot disk with the backup, booting the backup in (position sda).

e. I want to TOTALLY AVOID having to reinstall any packages.

My Fedora 22 boot drive has the following directory structure:

.autorelabel, bin, boot, .config, dev, etc, home, lib, lib32, lib64, lost+found, media, mnt, opt, proc, root, run, sbin, srv, sys, tmp, usr, var

My tentative list of directories to exclude is:

/dev, /home, /media, /mnt, /proc, /run/media, /sys, /tmp, /var/lock, /var/run

/home is excluded because I rsync it separately. Under the assumptions of issue (1), I REQUEST DISCUSSION OF DIRECTORIES TO EXCLUDE.

(2) In my Linux-inexperience, and focusing on supposition (1)d above, I have speculated that /etc/fstab and /boot/grub2/grub.cfg may need special handling. My intent is:

a. On sda, copy /etc/fstab to .../fstab_sda and copy /boot/grub2/grub.cfg to .../grub_sda.cfg.

b. Exclude /etc/fstab and /boot/grub2/grub.cfg from the rsync, HOPING that the backup will therefore boot successfully from (position sdc).

c. If I want to replace the boot disk with the backup (booting the backup from position sda), I will replace .../fstab and .../grub.cfg with their ..._sda counterparts, HOPING that the backup will therefore boot successfully from (position sda).


(3) My research SUGGESTS that (1) + (2) above are overkill, and that I should abandon the rsync_on_the_root strategy in favor of:

a. Only rsync'g /home and /etc.

b. Maintaining a list of installed packages with dnf.

c. Restoring by using Fedora 22 Live to place the (full) Fedora 22 on a new disk, manually rsync'g /home and /etc on this new disk, and then using dnf to manually re-install the packages to this new disk.

d. Periodically checking for a newer version of the Fedora 22 (workstation) Live iso.

On my system, "dnf history userinstalled" reports only 24 packages since my ... (more)

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2016-02-12 15:02:58 -0500

Well, I have never been a big fan of blindly cloning your hard drive / partitions. It might seem easy, but it takes a lot of work.

There are tons of sets of instructions on cloning here and elsewhere -

The problems with such a strategy are:

  1. Backup / clones are best when the system is NOT running (ie from a live CD).

  2. Backups take a long time and are quite large.

  3. Restoration is not always trivial.

See - or similar for advice on such a strategy.

Personally, I use a simplified strategy and back up only

/home , any system file I manually edit (save a copy in /root and back up /root), and any system data / shared directories such as /var/www/html

Smaller backups and system files and packages are always available in the repositories. Reinstalling packages is rather trivial.

rsync will perform incremental backups and is quite efficient.

Perhaps something like this will work for you -

edit flag offensive delete link more


I don't think the previous answer tackled any of the three specific issues that I raised. Rsync vs clone is a separate issue; I'm happy enough with rsync. Also, I feel that these issues are best served by explicit responses, rather than referencing another webpage, unless that webpage specifically discusses/debates one of the three issues that I am raising.

zug234zwang gravatar imagezug234zwang ( 2016-02-12 21:12:24 -0500 )edit

There are many back up strategies, pick one =) I am not going to debate the merits of the various strategies with you . Keep in mind, you need to test to make sure your back up strategy works and that you can restore your data / system when needed.

bodhi.zazen gravatar imagebodhi.zazen ( 2016-02-16 06:14:32 -0500 )edit

Question Tools



Asked: 2016-02-11 00:52:10 -0500

Seen: 122 times

Last updated: Feb 12 '16