Linux Backup machen

atze303 schrieb:
Das könnte funktionieren. Bedenke aber sobald du VMs mit größeren disk images hast dann kann das backup dauern. Da immer die gesamte disk bei jeder änderung ubertragen wird.
Das hängt von dem Backuptool ab. Ansonsten lässt sich sowieso nicht alles ootb online sichern, u.a. VM-Images.
Ergänzung ()

Innensechskant schrieb:
Genau das kann es sehr gut, falls du BTRFS als Dateisystem einsetzt klappt es sogar mit Snapshots.
Für Backups reichen auch LVM Snapshots.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Innensechskant
Veeam Agent for Linux wäre vielleicht auch was.
https://helpcenter.veeam.com/docs/agentforlinux/userguide/installation_process.html?ver=60
https://www.veeam.com/products/free/linux.html?ad=downloads
Das muss man sich aber genau anschauen, ob es den Ansprüchen genügt, wenn man nicht noch zusätzlich den Veeam Verwaltungsserver auf Windows (only) installieren möchte.
Ansonsten läuft der Client auf dem Linux System und die extern angelegten SMB/NFS Backupimages können mit einem LiveRecoveryMedium wieder eingespielt werden.

https://www.wundertech.net/backup-a-linux-pc-to-a-synology-nas-using-veeam/
 
Zuletzt bearbeitet von einem Moderator:
@scooter010
Es gab einen Datenverlust bei Cloudanbieter Hetzner. Durch einen Defekt sind etliche Snapshots verloren gegangen. Im Anschluss gab es im Social-Web direkt viele gutgemeinte Hinweise darauf, dass Snapshots auch keine Backups sind.
Kein Schutz vor Hardwareausfällen
Keine Datensicherung außerhalb des Systems
 
Dann sollten wir die Definition eines Snapshots angehen.
Ein Snapshot eines laufenden Systems kann sehr wohl ein Backup sein, wenn es außerhalb der Umgebung aufbewahrt wird.

Snapshot an sich sagt IMHO erstmal nichts darüber aus, ob irgendetwas als Backup gilt oder nicht.
Ich habe achon Backups gesehen, die waren kein Backup.
Natürlich ist ein Backup nur ein Solches, wenn es außerhalb der Infrastruktur des Produktivsystemes läuft. Damit ist sogar das Berechtigungssystem gemeint. AWS-Services mit Backups bei AWS sind keine Backups.
 
Solange der TE nicht schreibt, welches System er hier einsetzen möchte...
Unter Debian benutze ich timeshift mit Ext4 und unter Fedora timeshift mit btrfs.
Für Fedora sind Änderungen bei der Partitionierung notwendig, für Debian und Arch nicht.
 
Ich habe nicht gesagt, dass snapshits backups sind. Snapshot können aber alternativ zum Dateisystem des zu sichernden Systems als Quelle für das Backup dienen.
Bei ZFS kann ein inkremenrelles raw zfs send | ssh ubrigens tatsächlich als backup fungieren.

Also snapshit selbst ist nicht das backup, aber dessen Übertragung auf einen anderen host
 
Moin @StefanArbe , warum nicht mit Rescuezilla ein Image der Partitionen machen. Die ISO-Datei von Rescuezilla lässt sich mit "grml-rescueboot" in das Grub-Menü des installierten Systems einbauen. Beim starten des System kann man dann die Iso-Datei booten und die Image anlegen. Die Installationsanleitung für "grml-rescueboot" kann ich dir liefern.
 
Habe ich gelesen. Die Argumente stimmen aber bei mordernen snapshots nicht mehr oder nur noch partiell. Hier muss natürlich gesichert werden. Aber Datenbanken sichert man doch in Datenbanken?! Sonst wird die wiederherstellungszeit unbeherrschbar. Bzw. bei verteilten Clustern die Synchronisation. Edit: Kann aber auch anders sein. Hatte nur eine oracle Lehrgang, da geht schon fancy shice. Mit dem ganzen redo-cache Kram komme ich heute noch nicht klar, zum Glück verwenden wir oracle nicht.

Bis auf die Sache mit dem Application state (Datenbanken) stimme ich dem allen nicht mehr zu, zumindest nicht, wenn wir über zfs oder btrfs snapshots reden, die verschlüsselt und inkrementel (Speicherplatzverbrauch nur Summe aller Schreibvolumina, caches sollte man natürlich wo anders hin legen) auf einen entfernten Host gespeichert werden. Hier kann man quasi beliebige Zeitpunkte des Dateisystems herstellen oder auch nur einzellne Dateien.
 
graywolf2 schrieb:
Snapshots sind kein Backup
Es geht hier darum einen online fähigen Zustand für ein Backup zu erreichen und nicht das Backup selbst durchzuführen.
Ergänzung ()

scooter010 schrieb:
Habe ich gelesen. Die Argumente stimmen aber bei mordernen snapshots nicht mehr oder nur noch partiell. Hier muss natürlich gesichert werden. Aber Datenbanken sichert man doch in Datenbanken?! Sonst wird die wiederherstellungszeit unbeherrschbar. Bzw. bei verteilten Clustern die Synchronisation. Edit: Kann aber auch anders sein. Hatte nur eine oracle Lehrgang, da geht schon fancy shice. Mit dem ganzen redo-cache Kram komme ich heute noch nicht klar, zum Glück verwenden wir oracle nicht.
Wenn dein Oracle Kram nicht in ASM Volumes liegt und dein Oracle nicht diesen merkwürdigen Modus fährt wo Commits nicht zwingend auf non volatilen Medien geschrieben wird und deine gesamte DB auf einen Medium liegt welcher atomar snapshotbar ist kannst du auch die Datenbankfiles aus einem snapshot sichern.
Im Fall der Fäller findet dein Oracle nach einem restore eine DB vor die wie nach einem Stromausfall oder einem Crash aussieht, also es werden angefangene Transaktionen weggeworfen bzw. andere aus dem Journal nachgefahren.
 
Zuletzt bearbeitet:
Zurück
Oben