Backup Strategie?

Hallo @all,

zuerst einmal super Sache, die ihr alle macht!

Wenn ich falsch bin, bitte nicht erschießen.
Wenn es heißt, ich soll Geld in die Hand nehmen, sagt was :wink:

Nun zu meinem Problem:

Meine QNAP TS-231 wurde 2-mal verschlüsselt „Qlocker“ wie auch immer das passierte?
Standard Admin aus. Ein Admin mit einem langen Passwort und der Name ist ebenfalls komplex.
Kein FTP, SMTM oder sonstiges. Der Login Port ist auch umgebogen.

Danach habe ich das Gateway in das NAS leer gelassen, damit das NAS nicht mehr Online kann.
Logischerweise funktioniert das „Hybrid Backup“ nicht mehr.

Wie kann ich jetzt ein automatisches Backup einrichten, ohne Gefahr zu laufen, dass wieder alles verschlüsselt wird?
Jetzt kopiere ich die Daten 1-mal in der Woche per Hand in die Google-Cloud

Ich habe noch ein:
Intel NUC i7-1165G7 2,80GHz 11th Gen
64 GB RAM
1 TB m.2
Proxmox 8
dort läuft nur ein Pi-hole LXE

Also wenn du in die Cloud willst ohne default Gateway… Setz doch eine direkte Route in die Cloud, dann kann auch nur dorthin kommuniziert werden.

Gibt sicher für die Google Cloud einen globalen DNS load balancer, den könnte man eintragen.

1 Like

Oha, die Antwort war schnell °°
Das werde ich mir am Wochenende mal anschauen :wink:
Wenn ich scheitere, werde ich wohl mal ein Termin vorschlagen ^^

Grüße

Servus.

Ich verstehe nicht, du hast Proxmox im Einsatz und du willst dein Zeug auf eine QNAP sichern? Warum? Setze dir einen Proxmox Backup Server auf, mache eine direkte /30 Verbindung von PVE ↔ PBS und dann ist das Zeug so gut wie sicher.
Oder hast du kein Proxmox sondern nur eins wegen Pihole CT? Selbst da könntest du ein PBS als VM aufsetzen und eine USB-Platte durchreichen, auf der deine Backups auflaufen.

Hallo Ruediger_es_ist

vllt ist die Antwort etwas :slight_smile: 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. :slight_smile:

Viel Erfolg.
Gruss
ELindemann

1 Like

Hallo zusammen,

vielleicht ist meine Überschrift falsch gewählt.

Vergessen wir mal Proxmox ; )

Ursprünglich war nur die QNAP vorhanden, an dieser ist noch eine USB Festplatte angeschlossen.

Ebenso gab es" Hybrid Backup Sync", was jede Nacht den Backupjob gestartet hat.

Zu meiner Schande kenne ich mich nicht so genau aus, was dazu führte das bei dem Angriff die NAS verschlüsselt wurde, die angeschlossene USB-HDD und der „Falsche Backup-Plan“ alles verschlüsselte in die Cloud überschrieben hat.

Meine… Naive Idee war:

Dass die NAS keinen Zugriff auf das Internet bekommt.

Irgendeine Installation auf z.b. Proxmox (Dieser dient nur als PiHole die HW ist total OP hierfür),

eine Software die Zugriffe auf die Netzwerkfreigabe der NAS hat,
und regelmäßig alle Änderungen sichert (Differentielle).

Ab und zu auch mal ein Vollbackup.