# Lewis
The Ubuntu server used for backups
## TODO: pull architecture
For security reasons, it's better to have a pull architecture for backups instead of push:
If one server is compromised, the backup server can also be compromised.
This is especially nasty in case of a ransomware attack.
After researching, pull is best done using [sshfs](https://borgbackup.readthedocs.io/en/stable/deployment/pull-backup.html).
NB: using sshfs with our current setup of hard-coded ssh keys seems badly scalable and annoying.
A better solution could be to use ssh certificates.
One negative side of pull, is that the backup server must now be aware of each server that has data to be backed up.
I designed our network to be as distributed as possible, such that it is easy to introduce new machines.
However, most machines that have data to be backed up will be virtual machines in the near future.
This data can therefore be saved on separate virtual disks.
The backup server only has to be aware of the physical servers running the hypervisors and back up these disks.
Fortunately, the amount of physical servers we own is unlikely to change much.
## TODO: off-site backups
Right now, all backup data is still stored on-site.
One potential place to store backups off-site is Amazon S3.
Another options would be HiDrive S3 from Strato.
## TODO: offline backups
Another improvement to our backup system is to incorporate offline backups.
I should investigate what is a good method to do this.
