What is the "canonical" method to backup a live system

Help
1

Is using the Installer the best (or only) way to properly backup a live system?
If I try to do let’s say a drag and drop from one drive to another, I wind up with “actual” folders of all the packagefs stuff, and this is a problem.
If I use rsync, what exact system files/folders do I copy? /boot/system/cache and /boot/system/var get populated at boot time with data I shouldn’t backup but do they also contain data needed for a bootable system?

I have a live system with over almost 2TB of data on it, and Installer wants to rewrite all that data every time.

What is the “canonical” or official method to backup a live system creating a second bootable system?

Perhaps we should have an article on the website addressing this too.

1 Like
2

To further clarify, I want to copy my live haiku system to an external USB drive that I can then boot on another computer if I wanted to.

3

Using Installer seems the simplest way to achieve this without surprises.

3 Likes
4

If you don’t want some data to be copied, the best would be to have them on a separate partition.
If you don’t have another partition handy, backup your data on a removable media, delete them, use installer to create your USB drive, restore the data from the removable media.

It really depends how you customized your install. If all you want is to have same packages installed, a better solution would be to create your USB drive normally. After that, copy the file activated-packages from administrative directory on your actual install to your USB install desktop, It’s a text file so it will help you to know what packages to install on the USB drive.

1 Like
5

After much experimentation over the past few days, the best way I’ve found to make a bootable clone that you can update reglarly is to use Installer to make a bootable clone of your live system, and to update it use rsync with the following parameters (replacing $TARGET with your backup drive name):

			rsync -v -r -u -l  --delete /boot/system/non-packaged/ /$TARGET/system/non-packaged/ ;

			rsync -v -r -u -l  --delete /boot/system/packages/ /$TARGET/system/packages/ ;

			rsync -v -r -u -l  --delete /boot/system/settings/ /$TARGET/system/settings/ ;
			
			rsync -v -r -u -l  --delete --exclude 'swap' --exclude 'shared_memory' --exclude 'log/syslog*'  /boot/system/var/ /$TARGET/system/var/ ;	
			
			rsync -v -r -u -l  --delete  /boot/home/ /$TARGET/home/ ;
3 Likes
6

The best thing would be to have the option in Installer to update only newer files but as it is now it will re-copy everything everytime. Therefore rsync is a better option for subsequent daily/weekly backups. Maybe we can have a “Backup” option in the menu of Installer.

7

It’s better to simulate first what is going to do with --dry-run

Edit: removed “Beware with —delete option, if target path doesn’t exist it would delete everything in the source path” 'cuz I was wrong :wink:

2 Likes
8

Actually, it will create a directory with the targets name and attempt to mirror the directories there. Or if you didn’t assign a name and just used “$TARGET” (which would now have no value), It would attempt to write to the root folder “/” which already has a pointer to system folder so it should throw an error at that point or do nothing because “source” and “destination” are the same. If you are watching it, you can catch it quickly. CTRL-C to cancel the operation. You shouldn’t lose files, just possibly duplicate your /boot/home folder in /home.
Not the end of the world but annoying.

“–delete is used to delete files in the destination directory if they don’t exist in the source directory.”

Needed to keep target up to date and in sync.

Yes, do a “–dry-run” first :slight_smile:

1 Like