Better backup strategy #1

New issue

Open

opened 2023-12-31 19:42:56 +01:00 by strix · 1 comment

strix commented

2023-12-31 19:42:56 +01:00

Owner

Right now we use a restic setup that works in the following way:

+--------------------+
|                    |
|  backup (restic)   |
|                    |
+---------+----------+
          | push
+---------v----------+
|                    |
|   backup server    |
|                    |
+--------------------+

This is bad because now every server has the keys to the backup server.
If one server gets hacked basically all servers can go bye bye.

we need an extra step:

                   +-----------------------+ 3 +---------------------+ 4 +-----------------------+
    1 & 2+--------->dedicated backup server+---> update witch restic +---> push to backup server |
         |         +-----------------------+   +---------------------+   +-----------------------+
         |
         |
         |dedicated server
         |pulls files with rsync
         |
         |
+--------+------+
| server |      |
| +------v----+ |
| |rsync on / | |
| +-----------+ |
|               |
+---------------+

This makes sure that the latest version is always on the server and the modifications are applied by the dedicated server.
Also this makes sure that if a server gets hacked the modified version can only be applied on top of the proper version and be rolled back at any time.

cron changes:

# dedicated server
0 0/2 * * *  # pull files every hour 2 hours
59 1/4 * * * # push files to backup server every 4 hours (one hour ahead of the pull schedule)

changes to all systems:

remove the old backup system
add rsync and a config file that allows the backup server to connect
@guest:deny, backup:ro
- password will be stored plaintext on all servers.
- password will be different for all servers.
  this is okay, since it doesn't matter that you have the password for one server as it's already compromised.

Right now we use a restic setup that works in the following way: ``` +--------------------+ | | | backup (restic) | | | +---------+----------+ | push +---------v----------+ | | | backup server | | | +--------------------+ ``` This is bad because now every server has the keys to the backup server. If one server gets hacked basically all servers can go bye bye. we need an extra step: ``` +-----------------------+ 3 +---------------------+ 4 +-----------------------+ 1 & 2+--------->dedicated backup server+---> update witch restic +---> push to backup server | | +-----------------------+ +---------------------+ +-----------------------+ | | |dedicated server |pulls files with rsync | | +--------+------+ | server | | | +------v----+ | | |rsync on / | | | +-----------+ | | | +---------------+ ``` This makes sure that the latest version is always on the server and the modifications are applied by the dedicated server. Also this makes sure that if a server gets hacked the modified version can only be applied on top of the proper version and be rolled back at any time. cron changes: ```crontab # dedicated server 0 0/2 * * * # pull files every hour 2 hours 59 1/4 * * * # push files to backup server every 4 hours (one hour ahead of the pull schedule) ``` changes to all systems: - remove the old backup system - add rsync and a config file that allows the backup server to connect `@guest:deny, backup:ro` - password will be stored plaintext on all servers. - password will be different for *all* servers. this is okay, since it doesn't matter that you have the password for one server as it's already compromised.

strix added the

labels 2023-12-31 19:42:56 +01:00

strix commented

2023-12-31 19:57:22 +01:00

Author

Owner

the dedicated server will use a custom docker image, as always open to the public.
it will include rsync, restic and ssh/sftp to push the restic image.

the dedicated server will use a custom docker image, as always open to the public. it will include rsync, restic and ssh/sftp to push the restic image.