I’m wondering if anyone has suggestions on the “best” way to backup several folders to, say, a USB drive at shutdown. I assume a script is the first option, but wonder if there is a way to do it otherwise.
Thanks for the help!
1 Like
I would say a systemd.service file would do. I had one somewhere as an example I’d need to look for it though. Give me a few moments.
1 Like
Thanks… That was my thought, too, after I ran across this page. I guess I’m also wondering if rsync, rdiff, or rdiff-backup would be best, as well.
I guess I’m also wondering if
rsync,rdiff, orrdiff-backupwould be best, as well.
For most normal backup scenarios rsync works alright, it just synchronizes two locations, original and backup.
Rdiff is a tool to compare two files and show the differences, or update one file with the changes in the other (patch).
Rdiff-backup is somewhat of a combination of the two above: it’s an incremental synchronization tool that keeps a history of the changes. So each time you run it, it will compare the locations, update the changes and log them.
Thanks for that… It would seem rdiff-backup makes the most sense, since I want to keep the folders on the internal drive mirrored with those on the external one.
Both rsync and rdiff-backup will mirror the two drives for you, but with the latter you could for example look back which files had been changed/added on a specific date, or rollback a certain backup if you prefer an older version. Rsync is just a one-time copy action, so it doesn’t keep any history.
1 Like
I’m also playing with rclone options due to its ability to run as many transfers in parallel as I’m willing to do.
rclone is also a nice option, especially when you want to backup stuff to external (cloud) locations.
Since the DE is GNOME, in the “simple tools doing their job” category I would recommend Deja-Dup Backups:
Déjà Dup is a simple backup tool. It hides the complexity of backing up the Right Way (encrypted, off-site, and regular) and uses duplicity as the
backend.
While the configuration happens via GUI, the backup can be started via CLI too, which can be included in a script (deja-dup --backup && shutdown -r or something more complex), and the script added to a custom keyboard shortcut.
1 Like
deja-dup is a really interesting option that I don’t know much about… Does it “sync?” That is, I’m looking for something that only backs up files that are changed…
I’ve toyed with rclone for the better part of the day and, once copied over the first time, I can get it to check for changes in over 6,500 files in under two minutes. Now, I don’t know if that time is “good” or not, tbh…
Yes it does. It works with incremental backups, i.e. it only copies parts of files that have changed since the last backup, and saves them in tar format signed with GnuPG. Backups can be password encrypted. The default back-end of Deja-Dup is duplicity, so its man page can provide further information.
This is an example of the home folder being backed up, and the option to restore specific files to a previous state.
I have no experience with performance, since my setup is to do automatic, password encrypted backups to Google Drive once per week (default, can be set to daily etc, or manually). When set to automatic, backups run in the background, I just get a notification in the Notification Center (can be disabled) when a scheduled backup is about to begin.
Given that only differences are backed up (as diff files), restoring backups I presume would take some time, since full files have to be recreated.
1 Like
Interesting… Thanks!
1 Like
Any process which delays shutdown is at risk of either preventing shutdown by getting stuck - something far from unlikely when removable media is involved, else being murdered by systemd or its affiliates.
Since you are starting from the desktop and emphasise shutdown, and from your question are looking for a method of automating the process and doing so cleanly, one approach would be to create a desktop action which runs your backup process then something like gnome-session-quit --power-off --force (to avoid being prompted). At the risk of over-engineering this, you might also lock the screen with gnome-screensaver-command --lock (or, more portably, xdg-screensaver lock) first, arrange for the backup process to notify on progress (if you allow notifications on the lock screen).
You would of course use this action instead of whatever method you currently use to exit the desktop and shut down the computer.
Just be sure that whatever process you create fails quickly and cleanly if the conditions for completing the backup - a writable storage location with sufficient storage - are not satisfied. You don’t want to find out later that the process silently and invisibly stopped working.
2 Likes
Good points, ajcxz0; thanks for them!
Welcome, @bryanmoore.
It occurred to me that you might not need --force for gnome-session-quit if the thirty second timer works as normal. I’ve not tested this yet, so would be interested if you or others do so first.
@hamrheadcorvette Would you still be able to come up with that example, I would love to take a look as well!
Here is a simple example to clone the directory /home/myuser (including subdirectories) to /mnt/backup:
Create /usr/lib/systemd/system/backup-home.service
[Unit]
Description=Backup home before shutdown
DefaultDependencies=no
Before=halt.target shutdown.target reboot.target
[Service]
Type=oneshot
ExecStart=rsync -a /home/myuser/ /mnt/backup/
RemainAfterExit=yes
[Install]
WantedBy=halt.target shutdown.target reboot.target
Enable the service:
$ systemctl enable backup-home.service
2 Likes
Now this is much appreciated, @litemotiv, thank you!
Would it be “wise” to use a --exclude /home/myuser/.cache flag with the rsync command?
Yes that’s not a bad idea, similarly the trashcan might be something that some people prefer to exclude too, that’s in ~/.local/share/Trash/