# Simple backup protocol for home user.



## Dave Lister (May 27, 2020)

I'm new to FreeBSD and have just installed a 12.1 release 32-bit version with Mate desktop, OpenOffice, Thunderbird and Firefox are all installed, and even the printer is working.  So before I inevitably mess things up, I am looking for some pointers on how best to go about backing up the system, apps and files and some pitfalls to avoid.  I would like to :-

1) Do an initial full system backup to a USB drive in case I seriously mess things up and have to start from scratch with a freshly formatted hard drive.

2) Do periodic routine backups of just my files.

I'm reading through the Handbook 19.10 *Backup Basics *and will likely follow the instructions on dump & restore, but I wanted to check in with the forum and see if there were any pearls you can offer me first. A GUI option would be nice but I'm happy to use the terminal.


----------



## SirDice (May 27, 2020)

No need to backup the whole system. It's typically quicker to do a fresh install than restoring a full system backup. Do make a backup of your important configuration files (/etc/rc.conf for example). If you want, create a list of installed packages and backup that list (everything can be quickly (re)installed from that list). Definitely backup /home or /usr/home. Depending on your situation you may want to backup each user's home directory separately.

Backups can be as simple as a regular tar(1) job, just store the tarball on a separate machine or disk (external USB disk for example).


----------



## chrbr (May 27, 2020)

http://www.wonkity.com/~wblock/docs/html/backup.html gives good hints. If your home is not in a separate file system you could use dump(8) and  restore(8) and mask directories with `nodump` to save space and unnecessary backup. Additionally you should try from time to time if you can restore any of your backups, just in case. Helpful notes for that should be on paper.

A tar() archives of the configuration files in /etc and /usr/local/etc have been often helpful in order to fix some mess I did more or less unintentionally. From my experience one need that more often than a full backup .


----------



## Sevendogsbsd (May 27, 2020)

I normally just use net/rsync to sync my user's /home to my NAS. I also back up a few customized files as SirDice mentioned. All I really care about is my data. It takes about 10 minutes for me to install FreeBSD so for my use case, backing up the OS is kind of pointless. If you do a lot of custom port builds and whatnot, there are I am sure other things you need to back up so you don't have to go through a lot of work to get back up and running. I normally use packages and feed a list of packages I use to `pkg` so that part is automated, sort of...


----------



## msplsh (May 27, 2020)

Rsync is the tool you want to use.  Put it in your crontab and forget about it (unless you get an email that it failed)


----------



## a6h (May 27, 2020)

An example:

```
#!/bin/sh
mkdir -p /backup/usr/local
rsync -a /etc /backup
rsync -a /root /backup
rsync -a /usr/local/etc /backup/usr/local
rsync -a /usr/home /backup/usr
```


----------



## 8bitGlitch (May 27, 2020)

msplsh said:


> Rsync is the tool you want to use.  Put it in your crontab and forget about it (unless you get an email that it failed)


Do you have to configure any mail daemon or logging to receive notifications if it failed or will it mail the 'root' account on failure?


----------



## Emrion (May 27, 2020)

If you installed your system on ZFS, you have the boot environments. See bectl(8) or beadm(1) (I recommend the latter).

This won't save you in case of disk failure but from your errors. See here for a comprehensive description: https://vermaden.files.wordpress.com/2018/11/nluug-zfs-boot-environments-reloaded-2018-11-15.pdf

But if you chose UFS, sorry...


----------



## Jose (May 27, 2020)

8bitGlitch said:


> Do you have to configure any mail daemon or logging to receive notifications if it failed or will it mail the 'root' account on failure?


You should alias `root` to a real mail account in /etc/mail/aliases, and test to see if you can send mail to the real account `echo 'This is only a test' | mail -s 'This is a test' me@example.com`. Don't forget to run newaliases(1) after you add the alias.

If this doesn't work, you could try dma(8) as Mjollnir suggests here.


----------



## msplsh (May 27, 2020)

You'll need to use -q on rsync otherwise you'll get mailed a bunch of status data every time it runs.

Follow the instructions above to alias root's mail to an actual address and test it.


----------



## Dave Lister (May 27, 2020)

Emrion said:


> If you installed your system on ZFS, you have the boot environments. See bectl(8) or beadm(1) (I recommend the latter).
> 
> This won't save you in case of disk failure but from your errors. See here for a comprehensive description: https://vermaden.files.wordpress.com/2018/11/nluug-zfs-boot-environments-reloaded-2018-11-15.pdf
> 
> But if you chose UFS, sorry...



Thanks, but I'm not using ZFS - though I did read some interesting stuff about it on an Oracle Solaris Admin website, so, it might definitely be something worth considering at a later date.


----------



## Dave Lister (May 27, 2020)

vigole said:


> An example:
> 
> ```
> #!/bin/sh
> ...



Thanks, this is great.  I think I'll follow everyone's advice to some degree. Somewhere I'll need to include code to mount the ext4 USB partition whether at the beginning of vigole's script if I opt to run the script manually (where I might put the USB drive in for backup and then later remove it), or have ext4 mount done automatically at boot up if I'm going to leave the USB drive in and have the script run automatically at times indicated in crontab.  Would I be correct in assuming that if set up a crontab to run the script at regular intervals but the USB drive was for some reason unavailable during one instance, that I would just get a nasty email?


----------



## ralphbsz (May 27, 2020)

There are two layers to distinguish here.

First, rsync is an (incredibly complex and powerful) simple copy program. OK, so I just called it both "complex" and "simple", does that mean that I've gone insane? No, it means that rsync has a simple external interface: it doesn't run by itself on a regular schedule, it doesn't e-mail root, it doesn't handle serious error by retrying. It actually doesn't even know what "backup" is, it simply copies things from point A to point B. It has lots of internal complexity (like recursing down directory trees, knowing which files don't have to be copied ...).

Second, cron knows how to run a simple program, run it on a regular schedule, send mail to root when the program "fails", and all that. The problem that msplsh mentions above with his suggestion of using "rsync -q" is: One of the things that cron does: if the program creates any output on stdout or stderr, it gets mailed to root. In the particular case of a backup program, that seems pretty silly; most people would prefer to not get an e-mail if the backup ran successfully and on schedule.

But: the suggestion of using "-q" throws the baby out with the bathwater. This means that if something goes wrong, it gets harder to debug: All you get is the final error message. And it gets harder to check whether the backup is doing the "right thing". Here would be my suggestion: wrap the rsync commands (without -q) in a little script, which saves the normal output of rsync somewhere (we'll discuss where next). Then the script checks whether the rsync commands succeeded; if yes, it ends completely silently (nothing on stderr or stdout), and nobody gets any mail. If rsync fails, the script gives sensible and human-readable output, and also fails with an error code; this is intended to cause cron to send the sensible output to the sys admin. For example:

```
Dear Charlie Root,

on Wednesday, 2020 05 27 at 14:27, the daily backup job failed. The last line of output from the rsync command was:
  E_ELEPHANT: A purple flying elephant ate the backup disk.
The log of the rsync command has been saved in /var/log/daily_backup.log.
Please review the log file soon, because newsyslog will rotate it at the end of the day, and scrub it after one week.

Respectfully,
    your /usr/local/sbin/do_daily_backup script.
```

Finally, where to store the logs? If they are not too outrageously long, /var/log/ is actually a good place for them. Sys admins will expect to find them there, and you can easily configure newsyslog to compress them, and only save the last few. Once you have that set up, it might actually a good idea to run rsync with the "-v" switch, and see more detail.

Oh, and setting up mail so it works correctly for root goes without saying. That's just necessary.


----------



## D-FENS (May 27, 2020)

If you use ZFS it's very easy to do incremental system backups. You just use `zfs send` to make a binary copy of your whole file system in a file or as a dataset. Then each time you want to back up incrementally, you use `zfs send -I`.
Restoring is as simple as booting from a rescue medium (if your main one does not work) and using `zfs receive` to overwrite the last changes. You could even recreate your system from the backup if necessary - again with `zfs receive`.


----------



## msplsh (May 27, 2020)

ralphbsz said:


> the suggestion of using "-q" throws the baby out with the bathwater.



No, because if you get mail, then you know you need to go run the command manually without the -q.  If you don't get mail, then everything is fine.  This is the [unix] way. 

Yes, running a script would be "nicer" but it also adds complexity and failure modes.  It's not too much to ask them to understand cron and run rsync with -a and simple target options.


----------



## Phishfry (May 28, 2020)

I recently started using `rsync`. The one thing I  cannot get working is the -p or --progress flag.
Does FreeBSD's rsync have this option?
My command usage looks like this:
`rsync -Wrvac src dest`
I see rsync also has a server/client arrangement.
At first I was so excited I wondered why this tool is not in base. Then I looked at the license and saw it was GPL3.
I was also messing with `cpio` for simple backups.


----------



## Jose (May 28, 2020)

Hm, I think `-P` worked for me the last time I used it. I used a much simpler command-line, though: `rsync -aP rsync://linuxhost.example.com/video .`

I was running `rsyncd` on the Linux host.

BTW, the `-a` option specifies `-r, --recursive`. No need to add it to command line, though it doesn't hurt to do so.


----------



## gpw928 (May 28, 2020)

I reckon that the first thing is to figure out is a strategy that meets your goals and how much capacity you need to store the backups.

I have to backup both FreeBSD and Linux systems.  Not all of them use ZFS.

I also value a backup system that gives me access to a time series of individual files immediately, on-line, on demand.

So I built a ZFS server.  It uses rsnapshot(1) to centrally manage the backup process.

rsnapshot(1) uses rsync(1) for data transport, and It's capable of both full and incremental backups.

You must configure an account on the backup server with ssh root access to the fleet (best to plan that early using group membership, and don't use the "root" account itself).

The ZFS file system used to store the backups on the backup server is compressed.

An incremental backup of eight hosts generally takes less than an hour (the incremental backup of an unchanged file is implemented as a hard link to the previous copy of that file on the backup server)

Periodically, I `zfs send` the entire ZFS backup file system to an external disk for off-site storage.


----------



## Dave Lister (Jun 1, 2020)

vigole said:


> An example:
> 
> ```
> #!/bin/sh
> ...



I finally managed to get a 4th UFS partition for backup of my FreeBSD on a USB drive that has 3 partitions reserved for linux .

I followed your example above but have problems with the last step as it slows to a crawl if not actually halts.  I thought it was too much data on the Desktop which contains some heavy folders so I excluded that using:-

```
rsync --exclude=/myhome/Desktop -arv /usr/home/myhome /media/disk/backup/usr/home
```

However, it still hangs after so many files are transferred - most of them cache files it seems.  I tried using cp instead of rsync, but it does the same.  I think maybe the USB drive is overheating with too many successive write operations.

When I kill the window, I need to use 
	
	



```
fsck -y /dev/da0s4
```
 to fix the the partition before mounting the partition again after reboot.

Any thoughts?


----------



## a6h (Jun 1, 2020)

I hope there's nothing wrong with your HDD/USB. Maybe large amount of small files! I clear my browser's cache folder, before executing any backup operation:

```
rm -fr ~/.mozilla/firefox/PROFILE/cache2
rm -fr ~/.cache/chromium
```
and always have an eye on `~/.cache`. In my case, and it may not apply to your situation, and you should not blindly do the same things, I always clear the content of `~/.cache` before each _non-daily manual _backups. And there are some minor consequences, such as having to rebuild the `fontcache` and I had to quit the X mode, because of existence of some sockets in .cache folder.


Dave Lister said:


> rsync --exclude=/myhome/Desktop -arv /usr/home/myhome /media/disk/backup/usr/home


*-a *is equivalent to *-rlptgoD*
You do not need to add '-r' option to rsync command. '-a' is enough.


----------



## Dave Lister (Jun 1, 2020)

vigole said:


> I hope there's nothing wrong with your HDD/USB. Maybe large amount of small files! I clear my browser's cache folder, before executing any backup operation:
> 
> ```
> rm -fr ~/.mozilla/firefox/PROFILE/cache2
> ...


If you have `/etc`, and `/root`, and `/usr/local/etc` rsync'd do you really need `/usr/home` backed up?  I mean if everything under `/usr/home/myhome` is either my-files that are backed up elsewhere anyway, and cache records, would the restored system be functional without them?

`~/.cache` is still stalling on me even when I rsync the sub-folders of `/usr/home` individually. I was hoping I might get away without it.

BTW, is restoring the system from the backup after a clean install simply a case of rsyncing the same directories but reversing the source and target destinations? Will rsyncing in reverse without a clean install repair most inadvertent damage to the system.


----------



## Hakaba (Jun 2, 2020)

What about restic and syncthings ?
I use scp to backup «config» files and syncthings to get my smartphone photo.
I will test restic for my home dir.


----------



## rootbert (Jun 2, 2020)

be aware that rsync is a sync tool - if you have an important file and then you do `echo "" > important.txt` you end up with an empty file that gets synced to your backup. I have probably used _all_ major backup tools within the last 20 years to find the best tool (yeah, I am a little obsessed with backups), and I recommend borg backup in the first place, restic on the second. (keep your keys for your borg backup in a save place!)


----------



## jmos (Jun 2, 2020)

rootbert said:


> be aware that rsync is a sync tool - if you have an important file and then you do `echo "" > important.txt` you end up with an empty file that gets synced to your backup.



That's written a little bit unclear: rsync doesn't blank your backup file untile you say "sync this file" - there is no automatic sync. And a sync is exact what most users want a backup to do: Please update my backup, so it is equal to waht I have on my harddrive. Also rsync knows some params with which you could avoid blanked files from being transfered. But: Overwriting a fine backup with accidental damaged files can happen. That's why I'm using svn for some software development even when I'm the only deveoper (rollback), two separated backup hardware and no automatic execution of a backup run.

Actually, there is no general recommendation for a backup, the scenarios are quite too different - even in this case for a "home user": A backup is more than a piece of software, it is a concept. But the following has proven more than once itself, and may be usefull for someone else here…:


1) Backup the package list:

`pkg info > packages_all.txt
pkg query -e '%a = 0' %o > packages_base.txt
pkg_cutleaves -l > packages_nodeps.txt`

The first contains all installed packages, the second contains those I have explicitly installed, and the third one contains only those packages that are not referenced by any other package; If I need to reinstall my computer I only need to reinstall the packages on the last list - and be done. The other two lists are more for control purposes. To use "pkg_cutleaves" you need to install it first.


2) Backup the system configuration:

`tar cf - /etc/ | gzip -f9 > etc.tar.gz
tar cf - /usr/local/etc/ | gzip -f9 > usr_local_etc.tar.gz`

For this you need root privileges; I recommend using tools like doas, super or sudo, so you can do such backups as user.


3) Backup databases:

If you are using databases like PostgreSQL, Mariadb etc. make a dump of each database. It makes sense to compress such a dump with "gzip" afterwards.


4) Backup user data:

"rsync" is the tool of choice for me. First I recommend to create a exclude file - because temporary and caching stuff will be automatically rebuilt, and thus it does not need to be backuped; Here is a little from my exclude file:


```
.cache/
cache/
Cache/
application_cache/
opcache/
.dbus
.fontconfig/
.fullcircle/
.thumbnails/
tmp/
lost+found/
.snap/
Downloads/
```

A typical rsync call to backup a users home would be:

`rsync -avz --exclude-from=/path/to/excludefile --delete --safe-links /home/whoever/ /path/to/target/`

I myself use the parameters "-rtDv" instead of "-avz"; A little reading in the man page of rsync does no harm if you want to use it 


Also the tool "nice" deservs a mention here, which can lower the priority of such a backup command  (so my computers runs as fast as ever while doing backups).

And at least: Everything can be packed together into a small shell script, and your ready. Very important: At the beginning always check your backups, later still check them every now and then. And do not forget to check the file permissions in the backup.

However, when using USB drives the file permissions are lost to the "classic home user" (and often causes error messages during the backup); In my opinion a NAS which can handle SSH or NFS (and not only Samba) is preferable (build your own, and you win full control over its operating system, and maybe you can do this without a fan). If you do such a backup regularly it runs quite fast; And it doesn't matter that a cheap NAS doesn't process 100MB/sec, or that the WLAN is slower than the USB cable. Otherwise you have to reformat the USB drive so that it is able to understand things like "rw-r--r--".


"GUI" was also asked: I once wrote a small tool for myself to do backups, with which my surrounding is also happy - and it is of course able to handle the above stuff completely:






						Portal – Joachim Moskalewski
					






					www.jmos.net
				




Called with the parameter "-d" it can also remind you if you have not made a backup for a longer time (configurable). But actually I should rework this tool…


----------



## jb_fvwm2 (Jun 2, 2020)

I use rsync with good results, but two caveats:  1) it seems to like 16G memory at least 
probably due to concurrency while backing up... 2) some files on the destination are identical
to newly backed up files, but ending in a tilde, like text.txt~, and remain past newer
backups, vs the expected behavior, being deleted,
 making the backup area larger than the source.  Not a problem in this
use case, but if someone knows if it is a switch rsync needs/doesn't need that I use
it would be useful to know.


----------



## ralphbsz (Jun 2, 2020)

jb_fvwm2 said:


> I use rsync with good results, but two caveats:  1) it seems to like 16G memory at least
> probably due to concurrency while backing up...


I run it on Raspberry Pis (1G memory) all the time. I've been running it since ... forever, when computers had very little memory.



> 2) some files on the destination are identical
> to newly backed up files, but ending in a tilde, like text.txt~, and remain past newer
> backups, vs the expected behavior, being deleted,
> making the backup area larger than the source.  Not a problem in this
> ...


On the target side, rsync creates backups of files it overwrites. That's the ones ending in tilde. This is probably useful when using it to copy directory trees, probably not useful when using it as part of a backup strategy. There is a command-line switch to turn it off and on, look at the man page. I would guess it's "-b", but please check.


----------



## jmos (Jun 2, 2020)

jb_fvwm2 said:


> 2) some files on the destination are identical to newly backed up files, but ending in a tilde, like text.txt~, and remain past newer backups, vs the expected behavior, being deleted, making the backup area larger than the source.


Add the parameter "-v" to rsync, and it tells you more about what's going on. Also check the file permissions and owners of your remote file system; Create a single file on your computer, rsync it, and check the rsynced file owner.

About memory: I've never noticed high memory usage on any computer. And as ralphbsz wrote: It  wasn't a problem long time ago when 1 GB memory was just woolgathering…


----------



## Dave Lister (Jun 3, 2020)

rootbert said:


> be aware that rsync is a sync tool - if you have an important file and then you do `echo "" > important.txt` you end up with an empty file that gets synced to your backup. I have probably used _all_ major backup tools within the last 20 years to find the best tool (yeah, I am a little obsessed with backups), and I recommend borg backup in the first place, restic on the second. (keep your keys for your borg backup in a save place!)



Thanks for the borg backup suggestion.  I tried it and it appears to have worked nicely.  Proof will be in the eating of the pudding if and when I try to restore after some failure.


----------



## rootbert (Jun 3, 2020)

Dave Lister said:


> Thanks for the borg backup suggestion.  I tried it and it appears to have worked nicely.  Proof will be in the eating of the pudding if and when I try to restore after some failure.


You're welcome. I use borg also with my clients, backing up many TB of small files. I tried many tools, and most of them showing their flaws once you have a serious amount of files and replicas in your backup storage or you want to restore a large amount of files from a backup long time ago. Not so with borg, it has not let me down, and deduplication is a great feature expecially for a home user because usually your data changes not so much - you can keep quite a lot of snapshots of your data without wasting too much space. However, as you have mentioned, testing the restore of files is of utmost importance. And I cannot emphasize enough to keep the borg keys in a safe place (or several places ;-) - a backup without the keys to recover the encrypted data is worthless.


----------



## Jose (Jun 3, 2020)

Dave Lister said:


> Thanks for the borg backup suggestion.  I tried it and it appears to have worked nicely.  Proof will be in the eating of the pudding if and when I try to restore after some failure.


Do a test restore before you have a failure. I learned this the hard way.


----------



## jb_fvwm2 (Jul 20, 2020)

jmos said:


> Add the parameter "-v" to rsync, and it tells you more about what's going on. Also check the file permissions and owners of your remote file system; Create a single file on your computer, rsync it, and check the rsynced file owner.
> 
> About memory: I've never noticed high memory usage on any computer. And as ralphbsz wrote: It  wasn't a problem long time ago when 1 GB memory was just woolgathering…


quick fix, especially before a restore if need be:
    to my question on page 1 of this thread...


```
cd /backup/root/.mozilla...     find... [ see below ]
cd /backup/root/.cache...
cd /backup/usr/home...
cd /backup/usr/local...
cd /backup/var...
cd /backup/usr/ports...
.... and any 7th portion of the filesystem(s) found extraneously populated...
```
`find . -type f -name "*~" -exec /bin/rm -v {} \;`

deletes the extra files to make the space used on the source and destination near equal.
[ usual caveat about deleting files on a backup applies... ]
and, substitute your /mnt for backup in the example(s)
....
BTW this simple command makes rsync much more a capable backup/restore tool IMHO.


----------



## meine (Jul 20, 2020)

Dave Lister said:


> I'm reading through the Handbook 19.10 *Backup Basics *and will likely follow the instructions on dump & restore, but I wanted to check in with the forum and see if there were any pearls you can offer me first. A GUI option would be nice but I'm happy to use the terminal.



I have two backups -- one that adds my files to all I ever made, and the other that is just a mirror of my home directory. With multiple users on a box, every user's home gets backedup (is that a word?). In case of a meltdown, I just install the system anew, so I only need to backup my files and system settings.

I have copies of system files like /etc/rc.conf /boot/loader.conf /etc/hosts etc. in my 'admin stuff' directory, so I don't have to bother backing them up separately. I use two 500GB USB external hard drives for the backups, they are stored away from my computer with their volume names taped on them.

The backups are simply done with net/rsync. For easy handling, I made two aliases to run the commands. `bak-all' is the incremental backup, `bak-now' is the mirror.


```
bak-all   rsync -az --info=progress2 --exclude-from=/media/bsd_all/exclude-list-rsync.txt /home/ /media/bsd_all/HOME_backup_all/ ; ( echo incremental backup @FreeBSD ; date ; echo ---------- ) >> /media/bsd_all/backup.bsd_all.log

bak-now   rsync -az --info=progress2 --delete --exclude-from=/media/bsd_now/exclude-list-rsync.txt /home/ /media/bsd_now/HOME_backup_now/ ; ( echo mirror backup @FreeBSD ; date ; echo ---------- ) >> /media/bsd_now/backup.bsd_now.log
```

I found out that it is rather important to check if the backup volume is mounted in the same place as where rsync writes the files to, prior to running rsync.

The command uses an exclude-file to prevent a bazillion useless cache files and iso-files to be backupped. Further it writes a few lines to a log file on the backup volume to keep track of the backups I've done.

The backups ave one disadvantage: I have to run them manually, have to fetch the hard drives first, mount them, etc. I just have to remind myself making backups more frequently.


----------



## jmos (Jul 21, 2020)

meine said:


> The backups ave one disadvantage: I have to run them manually, have to fetch the hard drives first, mount them, etc. I just have to remind myself making backups more frequently.


Known problem. My working solution:

using network instead of USB drives (just power them on and they are available)
backup script which stores a timestamp on execution
desktop notification when this timestamp is too old
make everything eyecandy and mouse usable


----------



## Mjölnir (Jul 21, 2020)

if you use tar(1), consider pax(1) instead.  It's default format is ultimately portable.
I.e. you can read the backup from any other OS box
do some sanity checks (assertions) on your backup: e.g. size(backup) >= size(source), #files, checksums, ...
*regularly (once a year?) do a recovery manœvre*
include the timezone name or offset in the timestamp, or use UTC, e.g. `date +%F_%R_%Z`
`pkg search backup` shows a subset of available solutions.  Either you find a good one or you change some to fit your needs.
IMHO dump(8)/restore(8) is still the most reasonable solution for UFS; it has disadvantages though.  2nd best is rsync.  Obviously these are a matter of personal preference.
with UFS, you can benefit from inserting an I/O scheduler (gsched(8)), pull my rc-script here


----------

