30 lines
1.5 KiB
Markdown
30 lines
1.5 KiB
Markdown
# 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.
|