Update 'README.md'
This commit is contained in:
parent
f074fbc5ed
commit
6952876401
1 changed files with 6 additions and 15 deletions
21
README.md
21
README.md
|
@ -1,22 +1,13 @@
|
|||
# Lewis
|
||||
|
||||
The Ubuntu server used for backups
|
||||
Lewis is our server used for backups.
|
||||
|
||||
## TODO: pull architecture
|
||||
## 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.
|
||||
Backups are implemented in a pull fasion.
|
||||
A single Borg backup repository is maintained on this server.
|
||||
Servers in our network expose a SSHFS share with files they wish to be backed up.
|
||||
Authentication of these SSHFS shares is done using SSH user certificates.
|
||||
|
||||
## TODO: off-site backups
|
||||
|
||||
|
|
Reference in a new issue