There are two backup targets: remote and local. The remote target is kept up to date on a rolling basis while the local backup is a snapshot taken every night at 03h00. The reason for this is that I'm often mobile, and the cost of downloading small numbers of files from the remote target is small, so if I needed to restore my entire machine I would use the snapshot to get most of the way there, and then download the files which have changed between the snapshot time and the present from the remote backup.
I use Backblaze B2 storage as a backup target. I used Backblaze on my mac and while there is no Linux client, their B2 backend is supported by duplicity (from community/duplicity). The script itself is a little complicated because I use GPG keys to sign and encrypt the files locally (referenced in my system through gnome-keyring — see Security). This runs every 2h via a systemd timer (see Systemd).
Restoring files is done via the restore script (because initialising all the keys etc. is longggggg).
<aside> ⚠️ Both backup and restore have been well tested by now, but I have yet to test the process of importing my keys on a new system and running the restoration process. I have a task for this in my backlog but it's really important to test!
</aside>
In order to have rapid access to backups when required, snapshots of the system are taken regularly using rsync to a local, encrypted drive (which has to first be initialised).
I use a backup script to take daily snapshots of my system using rsync to this drive. The drive is organised in monthly folders, which are constantly updated over the month. A maximum of four months is kept, with older months being culled.
This system is designed such that the drive is only decrypted and mounted when the backup runs (using a Systemd timer), the script then unmounts and locks the drive when it is finished. This goes some way towards preventing any attacks against my data (e.g. randomware) as the drive is left encrypted and unmounted most of the time.