4

I'm running a restore from a previous backup of my FreeBSD system, and run into trouble when restoring / (excluding mount-points). The problem is that /rescue fills the / partition (to the extent that I can't restore my entire / partition) by taking up more place than it originally did.

I suppose it's because /rescue contains links and not files, and that files, not links, are restored into my / partition. I've tried restoring with both tar and rsync:

( cd /mybak/ ; tar --one-file-system -cvf - . ) | ( cd /newroot/ ; tar -xpf - . )

and

/usr/local/bin/rsync -va --delete --one-file-system  /mybak/ /newroot/

Both methods lead to my problem. What can I do to properly restore (or initially backup) the / partition, including /rescue, so that the restore doesn't take up more disk space than the original?

poplitea
  • 457
  • 1
  • 5
  • 16
  • 1
    After some researching, it looks like this could be solved with `rsync` and its `-H` flag to preserve hardlinks. Any comments to this? – poplitea Dec 01 '12 at 13:19
  • 3
    My comment is if you can't fit a copy of everything in `/rescue` on your root partition you need to make bigger root partitions :-) Remember, empty disk is cheap, but full disks can be expensive (downtime). – voretaq7 Dec 01 '12 at 14:05

1 Answers1

2

As you surmised, the problem here is /rescue doesn't contain many files - it contains one file (inode) with many names (hard links). As a result when backing up or restoring /rescue you need to use software that's aware of hard links.

For rsync this means the -H flag.

For tar this should not require any special magic: BSD tar (and GNU tar) are smart enough to know what a hard link is. For other backup programs, you need to check the documentation.

If you're using the regular Unix tools to make backups of your system (and grabbing whole filesystems) you may be better off using dump and restore. Aside from the ability to use UFS snapshots, there are other advantages to the more traditional utilities.

voretaq7
  • 79,879
  • 17
  • 130
  • 214