Gar nicht. Ich schieb da nur gepackte Verzeichnisse und DB-Dumps hin und her.
Echte Verzeichnisstrukturen mit den ganzen Einzeldatein mit rsync abzugleichen tu ich mir nicht an.
Wird alles vorher in handliche Pakete verpackt. 
Backups: Push or Pull
-
aRaphael -
February 15, 2024 at 2:07 PM -
Thread is Resolved
-
wozu dann rsync und nicht scp?
-
wie restorest Du dann die permissions?
Schau dir mal --fake-super in der rsync manpage an.
-
wozu dann rsync und nicht scp?
Weil ich gestaffelte Backups habe. Manches wird auf dem Server täglich als Backup gepackt, manches wöchentlich und anderes wieder unregelmäßig, nach Event getriggert. Da muss ich nicht alle Pakete jeden Tag durchs Netz jagen, sondern sichere nur die geänderten. rsync hat sich dafür am praktischsten erwiesen.
-
mir gefällt ja am besten der append-only mode von borgbackup.
-
mir gefällt ja am besten der append-only mode von borgbackup.
so lange man mit den Zugangsdaten nichts anfangen kann und borgbackup hier kein Sicherheitsproblem - auch bisher unbekanntes - hat ...
ansonsten genau so schlecht wie 'Push';
-
Backups: Push or Pull?
Wie macht ihr das, wenn ihr Backups eines Servers auf das Backupmedium übertragt?
Schiebt der Server das aktiv dorthin oder holt sich das Ziel die Dateien ab (falls möglich)? Gründe?
Hier läuft das mit mehreren Servern so:
1. Borg macht jede Nacht auf jedem Server ein Backup zu einem Storage-Server, der nur dafür da ist. Zeitraum für die Sicherung: 6 Monate2. Der Storage-Server hat ein VPN zu einem anderen Standort, wo ein NAS mit RAID 1 steht, zu dem dann mit rsync die Daten von Borg synchronisiert werden und as auch nur dafür da ist.
3. Die NAS wird wöchentlich auf mehrere externe Festplatten gesichert, die abwechselnd genutzt werden. Nur das Wechseln der Festplatten muss noch von Hand erfolgen. Aber ich arbeite an einer Automatisierung
Ja, die Server sind relativ wichtig, sonst würde ich den Aufwand nicht machen. -
ein Sicherheitstipp bei Backups aRaphael , dieses NIE als Push, immer nur als Pull, und das von einer 'versteckten' Stelle;
Warum? kracht da was in den Server, dann kracht das auch weiter zum Backup;
Wenn der Server kracht, wird Pull auch nicht mehr funktionieren und wenn der Server mitten während eines Pulls kracht, sind die Daten trotzdem unvollständig. Ich sehe da keinen Unterschied. Und Backups sollten ohnehin redundant vorliegen und auch als externe Offline-Kopie.
-
offline nicht unbedingt, Hauptsache an verschiedenen Standorten
-
offline nicht unbedingt, Hauptsache an verschiedenen Standorten
Bei "Push" vom Server aus könnte theoretisch ein kaputtes Script oder ein Angreifer auch die Backups an externen Orten zerstören, wenn die dauerhaft vebunden sind. Und ein dauerhaft laufendes NAS könnte auch mal Defekte haben. Deshalb ist eine zusätzliche Offline-Sicherung schon sicherer.
-
Bei "Push" vom Server aus könnte theoretisch ein kaputtes Script oder ein Angreifer auch die Backups an externen Orten zerstören,
damit hast Dir gerade selbst Dein Mißverständnis ausgeräumt;
in den Server krachen != Server krachen
-
damit hast Dir gerade selbst Dein Mißverständnis ausgeräumt;
in den Server krachen != Server krachen
Korrekt
Deswegen ja auch Offline-Backups als zusätzliche Absicherung
