Hallo Ruediger_es_ist
vllt ist die Antwort etwas 
zu spaet, evtl. jedoch eine sehr gute, einfach(?) umsetzbare Loesung.
Behmann hat hier schon den Proxmox Backupserver ins Spiel gerbacht. Ich kenne Proxmox in einer uralten version; wahrscheinlich, sicher ist Proxmox eine tolle Umgebung, die viele einsetzen.
Ich wollte Dir etwas anderes vorschlagen.
https://restic.readthedocs.io/en/stable/
Das Problem ist doch immer, wie schafft man, dass die Backup-Maschine NICHT befallen, nicht uebernommen wird. Wenn es auch HDs laeuft muss man etwas tricksen, oder man nimmt LTO Baender mit flexbackup, das nur als Info.
Kurz zum Konzept:
Mit der o.a. Praemisse, dass die Sicherungs-Maschine nicht fallen darf, muss man paar Punkte umkehren.
SrvA → SrvB gezogen, gesichert.
Als Sicherung-Werkzeug empfehle ich Dir restic, imho gibt es NIX Besseres, mir hat es (nicht wegen eins Cyrpto-Trokaners, sondern weil man vergass das Band einzulegen) in der Produktion, also nicht @home zwei Mal einen Datenverlust abgefangen, weil die Chefs selbst - obwohl so oft wiederholt - die Sicherung vor Ort haben schleifen lassen, I…en. Also auch die Mannschaft hat es nicht besser gemacht.
Doch restic bringt Dir alles 1:1 rueck. Hat gigantische Vorteile.
Das Vorgehen:
- SrvB sollte per auto-ssh sich bei SrvA einloggem koennen und Befehle absetzen.
Suche mal bitte im Web, wie man das konfiguriert.
Damit kommt dann der Benutzer [root] von SrvB ohne nix auf SrvA, kann so dort schalten und walten, sprich nix Interaktives mehr, sondern man/Du kannst per ssh remote Befehle absetzen.
-
ssh Benutzer_hohe_Rechte@SrvA -t „_ein_mount_Befehl, nfs, smbmount was auch immer“
setzt voraus:
-
NFS auf SrvB installieren, freigeben fuer SrvA; ip/32 engt alles auf nur diese IP ein.
Schau bitte nach, wie man NFS einrichtet.
-
mkdir auf SrvB [wohin_SrvA_gesichert_werden_soll]
-
mkdir auf SrvA [Dir_SrvB_in_SrvA_Pfad]
-
ssh root@SrvA -t „mount IP_SrvA:/media/[wohin_SrvA_gesichert_werden_soll]/media/[Dir_SrvB_in_SrvA_Pfad]“
Wenn Du bisher alles erfolgreich umsetzen konntest, haengt, das, was Du von SrvA auf Srv B sichern willst, z.B. per NFS (s.o.) auf SrvB.
Damit kann SrvB mit restic (cave verschluesselt :-)) voellig autark die eingegaengten Dirs von SrvA als seine Pfade sehen und auf seine eigenen Platten ziehen.
restic geht den Process von dir1 auf SrvB auf sein vorher auf SrvB angelegte Repo an.
Der Restic-Lauf wird natuerlich protokolliert und man kann extrem viel mit restic einstellen, viele Generationen wann/wo etc man behalten will.
Was Besseres kenne ich wahrlich nicht. restic kann mit rclone auch in die Cloud sichern, da der Datensatz von restic selbst verschluesselt wird, ist das alles ziemlich sicher.
D.h. wenn so umgesetzt wird, hast Du einen SrvB, der max. dicht ist, nur per ssh erreichbar waere und per ssh auf SrvA agiert und damit auch nicht uebernommen werden kann. Sprich, Du hast wenn Du diese Sicherung 1xd machst jeden Tag eine Sicherung von SrvA auf SrvB, die aufgrund der DeDuplizierung selber Staende kaum Platz in Anspruch nimmt, 1x laeuft es laaange, danach recht flott.
Solltest Du mal merken, dass Du eine Infektion am Tax X vor z.B. zwei Wochen bekommen hast, kannst Du halt die letzte Sicherung genau davor einspielen. Fast wie mit einem Band.
Viel Erfolg.
Gruss
ELindemann
