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
|
# 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:
|
Backups are implemented in a pull fasion.
|
||||||
If one server is compromised, the backup server can also be compromised.
|
A single Borg backup repository is maintained on this server.
|
||||||
This is especially nasty in case of a ransomware attack.
|
Servers in our network expose a SSHFS share with files they wish to be backed up.
|
||||||
After researching, pull is best done using [sshfs](https://borgbackup.readthedocs.io/en/stable/deployment/pull-backup.html).
|
Authentication of these SSHFS shares is done using SSH user certificates.
|
||||||
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
|
## TODO: off-site backups
|
||||||
|
|
||||||
|
|
Reference in a new issue