Vorhaltung Backup - generelle oder variable Methoden?

beartooth

Ensign
Registriert
Jan. 2020
Beiträge
185
Guten Tag zusammen,

ich arbeite mich seit ein paar Monaten in das Thema Server bzw. damit einhergehend Linux (Debian, Ubuntu) ein, und habe ein sehr wichtiges Thema bislang noch nicht behandelt: Backups.

Kein Backup, kein Mitleid.

Vermutlich werde ich erstmal versuchen, meinen Testserver mit rsync auf eine StorageBox bei Hetzner abzulegen. Meine Frage hierzu wäre, wie oft ihr Backups macht, und wie lange ihr diese behaltet? Hat das, was auf dem Server läuft, einen marginalen Einfluss auf die gewählten Intervalle?

Aktuell überlege ich tägliche Backups 30 Tage vorzuhalten, wöchentliche 3 Monate, monatliche 12 Monate, und dann quartalsweise bis zu 2 Jahren. Macht das Sinn? Ist das schon zu viel, zu lang?
beartooth
 
Das mußt Du doch wissen. Nur Du kennst Deine Anwendungen, nur Du kannst die Wichtigkeit Deiner Daten festlegen. Wie oft löscht Du Dinge? Wie oft passieren Fehler? Wie schnell mußt Du mit einem Ausfall rechnen? Wie hoch ist der Verlust im Delta zwischen den Backups, wie aufwändig ist das wieder herstellen verloren gegangener Daten?

Ich lösche beispielsweise grundsätzlich nicht an eigen erstellten Daten. Daher spielt es bei mir keine Rolle, ob ein Backup 30 Tage oder 10 Jahre alt ist.
 
  • Gefällt mir
Reaktionen: Blende Up und tollertyp
beartooth schrieb:
Meine Frage hierzu wäre, wie oft ihr Backups macht, und wie lange ihr diese behaltet? Hat das, was auf dem Server läuft, einen marginalen Einfluss auf die gewählten Intervalle?
Das, was auf dem Server läuft, hat selbstverständlich maßgeblichen Einfluss, wie häufig man Backups machen sollte.

Wenn man einen Server hat, der nur als VPN dient, dann braucht es kein tägliches Backup, da ist halt wichtig, dass man immer die aktuelle Konfiguration gesichert hat, in welcher Form auch immer.

Wenn es ein E-Mail-Server ist, dann ist tägliches Sichern der Daten das mindeste, was ich erwarten würde.

Wie lange diese dann vorgehalten werden, das steht dann halt auch auf einem anderen Blatt. Spielt der Verlauf der Daten eine Rolle? Geht der aus dem aktuellen Backup bereits hervor oder sind dafür Vergleiche mit vorherigen Backups nötig?


Beispiel: Ich habe einen IONOS-VPS, über den mein NAS eine VPN-Verbindung aufbaut, so dass ich über den VPS auf mein NAS zu greifen kann. Von dem VPS mache ich gar keine Backups. Die Konfiguration und die Schritte, die ich machen muss, die habe ich aber dokumentiert. Wenn ich etwas an der Konfiguration ändere, dann passe ich auch meine Dokumentation an.
Die Dokumentation selbst muss ich halt auch gegen "Verlust" absichern.
Bei der Konfiguration ist mit der Verlauf vollkommen egal, also mich interessiert nicht, wie die Firewall-Regeln von 6 Monaten aussahen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: beartooth und nutrix
Kommt nun darauf an von was.

Manche Sachen soll man ja nie löschen. Deine Foto Sammlung machst du doch nicht nach 2 Jahren weg

Bei einer Webseite u Datenbank mag das was anderes sein da wird man nicht, den Stand von vor 1 Jahr herstellen wollen

bei hetzner wird meine ich auch borg backup unterstützt
 
  • Gefällt mir
Reaktionen: beartooth und tollertyp
Es gibt eine einfache Regel, je kritischer das Delta der Änderungen, desto höher und kürzer müssen die Backups oder Snapshots sein.
 
  • Gefällt mir
Reaktionen: beartooth, Cardhu und tollertyp
beartooth schrieb:
Vermutlich werde ich erstmal versuchen, meinen Testserver mit rsync auf eine StorageBox bei Hetzner abzulegen. Meine Frage hierzu wäre, wie oft ihr Backups macht, und wie lange ihr diese behaltet? Hat das, was auf dem Server läuft, einen marginalen Einfluss auf die gewählten Intervalle?
schau dir mal restic an:)

Da hast du
  • Kann direkt auf die storagebox schreiben
  • versioniert gescheit
  • verschlüsselt ordentlich
  • Inkrementelle Backups
Mit rsync machst du dir halt valide Backups platt und hast damit weniger Schutz vor Schadoftware
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: beartooth und andy_m4
beartooth schrieb:
Meine Frage hierzu wäre, wie oft ihr Backups macht, und wie lange ihr diese behaltet? Hat das, was auf dem Server läuft, einen marginalen Einfluss auf die gewählten Intervalle?
Ich mache tägliche Backups von meinem Heimserver und PC.

Allgemein will man beim File-Server eher weit zurück gehen um an ein halb vergessenes Dokument zu kommen als z.B. bei einer Pihole VM, die läuft oder nicht läuft und auch kein immenser Aufwand wäre wenn man die neu erstellen muss.

Aufgrund von Platzbeschränkungen (4x 14TB Raid 5 als Backup Speicher, keine freien Slots am NAS) gehe ich 30 Daily und 8 Weekly in die Vergangenheit.
Wobei das auch aus meinem eigenen Tick kommt, alle 2 Monate ein Fullbackup zu machen. Mit forever-incremental würde da mehr gehen, dann könnte ich vermutlich 12 monthly problemlos hinzufügen.

Ich bin an der Stelle möglicher etwas paranoid bin bezüglich 'leiser' Korruption meiner Backups - insbesondere da ich Veeam nutze und den health check des Backup wöchentlich laufen lasse. Aber ich habe auch schon korrupte Backups erlebt und das macht keinen Spaß.

beartooth schrieb:
Aktuell überlege ich tägliche Backups 30 Tage vorzuhalten, wöchentliche 3 Monate, monatliche 12 Monate, und dann quartalsweise bis zu 2 Jahren. Macht das Sinn? Ist das schon zu viel, zu lang?
Das halte ich ehrlich gesagt für zu viel des Guten. Ich meine - wenn du den Storage hast warum nicht, aber sonst wofür? Wann erwartest du jemals, 2 Jahre zurück gehen zu müssen?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: beartooth
Mit rsync kann man auch versionieren. Einfach per cp hardlink eine neue Kopie erstellen und dann darein rsync laufen lassen. Aber das war früher.

restic ist schon gut.
 
  • Gefällt mir
Reaktionen: beartooth und madmax2010
beartooth schrieb:
Meine Frage hierzu wäre, wie oft ihr Backups macht, und wie lange ihr diese behaltet?
privat:

  • jeden Tag: Sicherung OS SSD lokal auf einen Internen Datenträger (eine Versionskette: 1x im Monat Vollbackup und danach nur noch inkrementelle)
  • jeden Tag: Sicherung Wichtige Daten lokal auf einen Internen Datenträger (eine Versionskette: 1x im Monat Vollbackup und danach nur noch inkrementelle)
  • jeden Tag: werden diese beiden Backups auf ein NAS gesynct
  • jeden Monat: Vollbackup vom Produktivsystem auf ein NAS
  • Nach dem Vollbackup wird ein Externer Datenträger an das NAS angeschlossen und das Vollbackup sowie die aktuelle Version der TagesBackups auf die Externe SSD kopiert
  • Danach wird die Externe Platte auf eine weitere gespiegelt, dabei werden auch Prüfsummen erstellt, womit der Datenbestand auf den NAS abgeglichen wird.
  • Wenn der Datenbestand mit dem des NAS übereinstimmt, werden alte Backupversionen gelöscht auf den Externen Platten und auf den NAS

geschäftlich (in Teilen da diese mit zum Geschäftsgeheimnis gehören) :

  • durchgängig laufendes Backup aller Veränderungen auf den Netzlaufwerken
  • täglich: Sicherung des Backups auf LTO Bänder für einen Monat
  • täglich: Sicherung extern mit verschiedenen Versionsketten etc. - mehr als ein Jahr
 
  • Gefällt mir
Reaktionen: beartooth, nutrix, madmax2010 und eine weitere Person
Ich denke man sollte den Typ des Backups nicht außer acht lassen.

Ich mache nur noch Backups per Blockebene und nichts aus den Dateisystemen oder per Agent auf oder in die laufende Laufzeit.

Mein privates Storage wird natürlich anders gesichert als berufliche Umgebungen
 
Vor allem sollte man sich darüber Gedanken machen, ob meine Daten überhaupt Backup fähig sind...

Was nutzt es mir, wenn ich von ner Datenbank what ever alles wegkopiere und dann am Ende unterschiedliche Stände da sind, weil auf der Datenbank gearbeitet wird während dem Backup.

Kann man die aber während dem Backup abschalten kein Problem....

Danach kann man sich dann über ganz vieles Gedanken machen.

Systeme an sich gehören meiner Meinung nach nicht ins Backup sondern die Config und der Weg um Sie produktiv zu haben. Das noch versionen und ich kann beliebig up und downgraden und Revisionen machen.

Ich bin z.b. ein Freund von ZFS oder Dergleichen mit Copy on Write. Damit kann man saubere Backupstände definieren und sich mit Snapshots auch kostengünstig viele Versionen vorhalten.

Die Snapshots dann einfach ausdünnen.

Zum Beispiel 1 Woche stündlich Backups
1 Monat tägliche Backups
1 Jahr wöchentliche Backups
2 Jahre monatliche Backups
- Bis hierher hat man an sich nur 3 echte Backups, da man ja das meiste nur über Snapshots macht.
3+ Jahre quartals/jährliche Backups irgendwo in ein Archiv Mit offline Medien wie Tape.

Da sich Daten oft nicht ändern bleibt das Ganze trotzdem relativ schlank.

Mit ZFS Replication sync oder async kann man sich zur normalen Verfügbarkeit ein live Backup ziehen.

Danach dann halt noch ein richtiges über die Snapshots und fertig ist der Drops. So lange nicht 3 Systeme abrauchen hat man noch seine Daten und selbst wenn das Peoduktivsystem zerstört wird kann man auf die erste Backupstufe ausweichen.

Ansonsten halt die Backup Methode der DB etc verwenden.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: beartooth und tollertyp
Skysnake schrieb:
Systeme an sich gehören meiner Meinung nach nicht ins Backup sondern die Config und der Weg um Sie produktiv zu haben. Das noch versionen und ich kann beliebig up und downgraden und Revisionen machen.
Sehe ich auch so. Deshalb habe ich bei mir ja dokumentiert, wie ich den VPN-Server einrichte.
 
Skysnake schrieb:
Systeme an sich gehören meiner Meinung nach nicht ins Backup sondern die Config und der Weg um Sie produktiv zu haben. Das noch versionen und ich kann beliebig up und downgraden und Revisionen machen.
Eine Meinung, die mit nur einem Bruchteil der existierenden Software kompatibel ist...

Skysnake schrieb:
Was nutzt es mir, wenn ich von ner Datenbank what ever alles wegkopiere und dann am Ende unterschiedliche Stände da sind, weil auf der Datenbank gearbeitet wird während dem Backup.

Kann man die aber während dem Backup abschalten kein Problem....
#linuxthings

Man kann Windows viel ankreiden, aber VSS ist echt bequem. Kompatible Software kommt application consistent ins Backup ohne Unterbrechung der Erreichbarkeit.
 
  • Gefällt mir
Reaktionen: tollertyp und Sebbi
Rickmer schrieb:
Eine Meinung, die mit nur einem Bruchteil der existierenden Software kompatibel ist...
Welcher Bruchteil an Software?

Unter Linux habe ich so schon zick Umgebungen komplett abgefrühstückt und wüsste kaum einen Grund warum. Das nicht gehen sollte. Wenn dann ne Anwendung aus dem Windows Universum. Und da würde ich dann versuchen in einen Container zu zwingen.

Rickmer schrieb:
#linuxthings

Man kann Windows viel ankreiden, aber VSS ist echt bequem. Kompatible Software kommt application consistent ins Backup ohne Unterbrechung der Erreichbarkeit.
Startpost gelesen?
 
Skysnake schrieb:
Unter Linux habe ich so schon zick Umgebungen komplett abgefrühstückt und wüsste kaum einen Grund warum. Das nicht gehen sollte. Wenn dann ne Anwendung aus dem Windows Universum. Und da würde ich dann versuchen in einen Container zu zwingen.
Bei jedem deiner Beiträge wird aufs neue deutlich, dass du in einer Datacenter Bubble lebst und noch nie bei einem durchschnittlichen KMU in die IT geschaut hast...
 
Was heißt Durchschnitt?

Die Einmann Hero Show?

Also mit Ansible, Chef, Terraform, Puppet oder wie Sie alle heißen, gibt es keinen Grund von Hand zu frickeln. Zur Not mit Bash Skripten ist noch immer besser als von Hand irgendwas zusammen zu bauen.

Vor allem, wenn ich das von Hand gemacht habe ist es kaum Aufwand das zu Skripten uns in ein Git zu packen.

Sobald du dich mit 2-3 Leuten in Vollzeit um die Systemadminitrarion kümmerst, also devops machst kannst du das stemmen.

Hatten wir im alten Betrieb auch gemacht. 2-3 Leute haben die Prozesse entwickelt als Dienstleister und 5-6 Leute hab es umgesetzt und betreut. Aber ja, durch das Peojektgeschäft haben wir uns den Arsch aufgerissen.
 
Rickmer schrieb:
Man kann Windows viel ankreiden, aber VSS ist echt bequem. Kompatible Software kommt application consistent ins Backup ohne Unterbrechung der Erreichbarkeit.
Linux kennt auch Snapshots und jede Datenbank bietet eine konsistente Backupfunktion an

"während dem Backup abschalten" da würde keiner Backups machen so
 
Kann aber ne Weile dauern. Hab das auf die harte Tour mit Timescaledb gelernt. Wenn die größer wird kann das Stunden dauern das Backup zu generieren und in der Zeit kann man keine Daten schreiben. Gibt zwar auch Lösungen, aber 0815 ist das dann leider nicht.

Wie gesagt, Anforderungen definieren und schauen wie man diese umsetzt.
 
Timescaledb ist doch nur ein Plugin für PostgrseSQL, oder?

In einem KMU fährst du die Datenbank runter, synct und machst einen Snapshot über das Volume. In größeren Umgebungen streamst du alles auf einen Backup-DB. Da ist es auch egal wie lange das Backup dauert, weil da nur das Backup läuft.
 
  • Gefällt mir
Reaktionen: TomH22
Eure Diskussion in allen Ehren, ich steige hier aus, finde es immer schlimm, wenn solche Fragen in derart allgemeiner Form gestellt werden, und sich dann aus dem Thread verabschiedet wird, wie wenn es eien überhaupt nicht interessiert.
 
  • Gefällt mir
Reaktionen: JumpingCat
Zurück
Oben