Update 'README.md'
This commit is contained in:
parent
180445348e
commit
8d32df1069
1 changed files with 25 additions and 2 deletions
27
README.md
27
README.md
|
@ -2,6 +2,29 @@
|
|||
|
||||
The Ubuntu server used for backups
|
||||
|
||||
## TODO
|
||||
## TODO: pull architecture
|
||||
|
||||
- Implement pull instead of push backups
|
||||
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.
|
Reference in a new issue