The Hotel Hero

The first idéa I had with this part IV, was to add Restic to the Rclone Backup server. But, due to higher complexity (It should be easy to backup and recover) and not least that it seems like Restic would need to be implemented on the host with Rclone (multiple instances). I skipped the idéa.

So, for now.

• If you are backing up UNIX to UNIX file system, you can sync.
• If you are backing up file with no special permission state to cloud/3s you can sync.
• If you backup from UNIX to storage with no permission scheme, you have to make a tarball (as shown in Part III copy/backup.sh, this tarball to preserve permissions.)

Using certificates to connect to external servers

In general we want to do different stuff to try and avoid bruteforce ssh attack on servers exposed to the internet.

• We could change ssh port from 22 to something else.
• Deny root login (very good idéa)
• Setup different firewall rules (can take some time)
• Deny access thru externally exposed ip addresses and limit it to internal addresses (not always easy).
• Deny login with user/password and only allow access with the right certificate.

So, to let Rclone access a remote server to carry out it's backup job. We could start by creating a new certificate on the backup server.

There is more in depth information at Rclone: https://rclone.org/sftp/ (basically there are 2 maybe 3 options)

ssh-keygen (and you could set different parameters, eliptic curv is most secure but can from time to time be unsupported on different servers)

Basically the above command would deliver a certificate (private and public file, idrsa + idrsa.pub)

ls ~/.ssh/
authorized_keys  id_rsa  id_rsa.pub  known_hosts  known_hosts.old

Either you have an existing user (or create a backup-user) on the remote server and copy the content of "idrsa.pub" to the remote server and users file (at the end of the file):

~/.ssh/authorized_keys

Alternatively you copy this from the backup server to the remote host:

ssh-copy-id -i /path/to/new_key.pub user@server_ip

After this we are able to login without password. Now we want to apply that private key to Rclone's config file (we could refer rclone to the original file, but then we would have to back that up too or keep it in a password manager and remember that our config file is encrypted with a password.)

The key needs to be a one-liner with \n as character.

awk '{printf "%s\\n", $0}' < ~/.ssh/id_rsa

Setup a new remote, skip "password" and use "key_pem" instead:

key_pem> -----BEGIN OPENSSH PRIVATE KEY-----\nc5BivnNxaC2rZ........

leave "key_file" empty. (that if you want to point to the key)

The rest I also choose the default option, I think the password for encryption is seen as a separate protection feature in OpenSSH. So, I don't provide any password here.

Last but not least

One thing that you also should consider beside this last backup is your PC. Everything in your "/home/username/." should be considered. From time to time we also have important settings elsewhere on our machine. But, a good practis seems to be keeping important stuff here (/home/user/*) and configuration else where might be keept in a remote git repository considered as configuration changes.

Devices ex. USB sticks. I have a tendency to be forgotten, they could contain your password manager file etc. Maybe make a calendar reminder to back these things up.

The backup server it self

The reason why i startet part III and VI here two years after Part I and II. Is actually that my SD-card on the old backup server (Raspberry pi) got bust. For some time I did'nt have the time or entusiam for setting it up again and try to recover it, if possible at all. But, as I lost some other data on one of my servers I saw the value of have full control of the automatic backup process and decided it was time to do it the right way again. Documenting everything and making it a routine to backup all vital data, including the backup server it self.

So, what is important to backup.

1. ~/.config/rclone/rclone.conf (our whole configuration is password encrypted)
2. I have all my individual bash jobs under ~/backup/* (I push changes to a private git repository)
3. And you may put a README.md in the ~/backup dir, that describes /etc/profile and your crontabs. 

We could probably encrypt the volume (crypt) and find a way to figure out how to decrypt the rclone.conf again. But, depending on where you are backing up. The biggest secret the rclone.conf file is encrypted and basically if the location you store your backup at is secured you should be safe. If you are storing your backup at Alibaba, Azure, GCP, AWS, I would say that you should do more, including using the "salt" option and encrypt all backups. Are you using a EU compliant and owned provider (GDPR compliant by law), you could be a bit less rigorous. But, with quant computing and the most powerful states that show no signs of holding back on industrial espionage (companies are bound by law to cooperate in this task) the above mention corporations are notorious for breaching the big C (confidentiality). I am just a realist here, everything else is wish full thinking.