Ideas: Automatic server backup/restore from chosen peer tildes #13
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(not sure this is the right place, duplicated it here: https://pad.bhh.sh/sjrTq9f1TQ-riwRVUDoTsQ?view)
a bit similar to RFC3 "Tilde Center Specification" (about synchronized user accounts on tildes).
Network of tildes may store backups for each other.
Script may automatically restore tilde server (by admin's command) in case of failure.
Tests that bring up a working copy of the system in a container may be regularly conducted.
If existing "cluster backup software", orchestration, or anything like that, can be used to achieve the result (probably setting it up in an unintended way), large part of this text is unneeded.
Basics
Server data may be split into:
In a network of servers, each server's configs backed up on 3-4 peer systems.
Number of backup sites/peers shall be chosen judging by reliability of selected peers.
I don't think that backup of each server on each server is needed.
Admins should know each other and understand stability of chosen peers.
Basics, master password
Sensitive data of the server can be encrypted and stored with configs at backup sites, while admins will keep only master password.
But probably it is better if admins will store all sensitive data personally - if their resources allow it and if they are confident in security of their personal systems.
Security
Integrity: hashes, public key cryptography for data, backups, peer servers, sender.
Access to backups may utilize schema, where 2 of 3 admins needed to decrypt archives and restore/setup new server.
Users
List of registered users - is "configs".
Encrypted user passwords may be stored either as "configs" or as "secrets".
Users data is "data".
Probably, users of the server may have a possibility to split their data to "configs" and "data" so their "configs" will be backed up on peer servers.
Users "secrets" should be backed up by users on their own (or users can choose to put their "secrets" in their "configs").
Execution
To perform recovery, the script will need access to both - backup on a peer server and a copy of "secrets" from one of the admins.
Tests
Regular tests should be scheduled, where admin restores and launches the server in virtual container.
Restore should result in fully functioning system (probably there should be self-tests).
Implementation
The system should use existing server orchestration software where its functionality is needed. Same for P2P data syncing.
System may differentiate between testing and real deployment (e.g. advanced testing setup may include mock letsencrypt service).
This is a moot point, as the tilde.center project died a while ago. Very interesting ideas, however.