Gibt es mit rsync eine Möglichkeit, Dateien die im Zielordner vorhanden sind, im Sourceordner aber mittlerweile gelöscht wurden - auch im Zielordner zu löschen?
Ich habe einen Backup-Ordner von mehreren VM / CT - dieser beinhaltet 7xdaily/4xweekly Images. Die Dateinamen sind mit Datestamp versehen. Per Rsync werden diese Backups täglich auf einen externen Rechner gezogen (Rechner startet automatisch, zieht das Backup über rsync / ssh und schaltet sich dann wieder ab)
Nun aber werden natürlich in diesem Ordner auf dem Backuprechner sämtliche alten Backups behalten ohne das sie gelöscht werden, was die HDD natürlich sehr schnell an die Grenzen bringt.
Gibt es bei rsync eine Möglichkeit die Dateien im Ziel welche im Source nicht mehr verfügbar ebenso zu löschen? Also quasi den Ordner auf dem selben Stand zu halten?
Schau dir mal das Programm BackInTime an. Es basiert auf rsync, und legt für jedes Backup-Datum ein neues Verzeichnis an. Unveränderte Dateien werden nur verlinkt, anstatt sie wiederholt anzulegen. Das spart eine Menge Platz und so hast du die alten gelöschten Dateien wie gewünscht nur in alten Backup Ordnern mit dem Datum als sie noch existierten.
Super praktisch ist dabei, dass man alte Backup-Verzeichnisse einfach löschen kann. Die Datei bleibt erhalten, bis alle die enthaltenen Verzeichnisse gelöscht sind.
Das Verfahren setzt ein Speichermedium mit ext4 Format voraus, auf NTFS würde Backintime die Dateien mehrfach anlegen anstatt sie zu verlinken.
Das Verfahren setzt ein Speichermedium mit ext4 Format voraus, auf NTFS
würde Backintime die Dateien mehrfach anlegen anstatt sie zu verlinken.
Auch NTFS beherrscht Hardlinks, weshalb es diese Technik nicht nur in Linux gibt, sondern auch in Windows. Da es hier aber um Linux geht: Wer verwendet da freiwillig NTFS?
Allerdings bringt es nur dann etwas, wenn ein Teil der VM-Images seit dem letzten Backup in keiner Weite angefasst wurde. Effizienter sind Verfahren, die auf Blockdifferenzen basieren, somit nur die paar MB vom Image sichern, die seither verändert wurden. Die sind aber komplexer und weniger narrensicher beim Restore.
PS: Das ist nun aber eine Diskussion, die sich bereits von der ursprünglichen und beantworteten Frage löst.
Effizienter sind Verfahren, die auf Blockdifferenzen basieren, somit nur
die paar MB vom Image sichern, die seither verändert wurden.
Effizienter ja, aber eben auch komplizierter. Ein simples unkomprimiertes Dateisystem hat einige Vorteile.
Bei mir sind gefühlt 95% der Dateien unverändert und für die anderen nutze ich gerne aus, das Massenspeicher billig gewirden sind. Irgendwelche unhandlichen Kompressionsverfahren tue ich mir nicht mehr an.
Bei mir sind gefühlt 95% der Dateien unverändert und für die anderen
nutze ich gerne aus
Kein Thema. Der TE hatte allerdings erklärtermassen VM-Images im Auge, und da werden die unveränderten 95% vom Image trotzdem kopiert. Irgendwann geht es ins Geld, von jedem 100 GB Image 12 fast identische Kopien als Backups rumliegen zu haben.
Wenn ich richtig informiert bin, beherrscht rsync doch das Sichern nur
der veränderten Blöcke. Oder verstehe ich das was falsch? Hab es nie
probiert.
Es reduziert nur den eigentlichen Kopiervorgang. Nützlich, wenn man ein bestehendes grosses File über eine langsame Fernleitung übertragen will. Es greift jedoch nicht, wenn sich Quelle und Ziel in direktem Zugriff befinden (inklusive NFS). Und da die inkrementelle Sicherung per rsync auf Hardlinks basiert, die nur ganze Files verdoppeln, erspart es auch keinen Platz.
Als Filesysteme können das mindestens ZFS und btrfs, da deren
Snapshot-Verfahren direkt die Grundlage dafür bieten.
Das muss ich mir mal ansehen. Ich kenne diese FS bisher nur vom Namen ;)
Danke.
Prinzip solcher Verfahren, auf Blockebene, nicht Files:
1
System A => System B
2
Snapshot A1 == B1 als Ausgangslage
3
Snapshot A2 Differenz A2-A1 => B2 als neuer Stand
Den Snapshot A1 kann man anschliessend löschen, nur A2 muss für den nächsten Lauf aufbewahrt werden. Die älteren Snapshots auf B kann man unabhängig davon aufbewahren oder löschen.
Nicht ungewöhnlich: System A verwendet SSDs, B aber dicke HDDs.
Welche Tools beherrschen denn die Sicherung nur veränderter Blöcke?
Allerlei NAS-Systeme, auch kleine wie QNAP (je nach Software).
Replikation einer primären NAS auf eine sekundäre, mit Snapshots.
Im Kontext von VMs kenne ich beispielsweise die darauf spezialisierte
Backup-Software von Nakivo.
Ich kenne diesbezüglich "Backup for Business" von Synology. Und ich bin damit in jeder Beziehung hochzufrieden. Das kann alles, Backups auf Filebasis und auch Backups auf der Basis von Images und dies sowohl für physische Maschinen als auch für VMs (zumindest Hyper-V und VMware) und das auch für Hochverfügbarkeits-Cluster.
Dazu gibt's dann noch (De-)Duplizierung und Komprimierung zum Platz sparen und Verschlüsselung für die Sicherung von Backups.
In der aktuellen Beta kommen dann noch WriteOnce-Backups für noch mehr Sicherheit hinzu. Dieses Feature habe ich allerdings noch nicht getestet.
Allerdings: bei den kleinen Home-NAS ist es wohl nicht verfügbar, obwohl rein technisch nichts dagegen spricht.
Die urspr. Frage wurde ja bereits beantwortet. Auch das Snapshoting mit zfs und btrfs auf Blockebene.
Nachdem rsync im Einsatz ist, werfe ich BorgBackup in den Raum. Also die fehlende Deduplizierung auf Dateiebene.
Warum? Ein normales NAS hat kaum die Ressorcen für zfs und dedupe. Und btrfs bleibt Wunschdenken bei Fertig-NAS-Büchsen.
Daher BorgBackup, ggf. mit Borgmatic aufgespannt, kümmert sich um die Platzverschwendung auf den üblichen Dateisystemen.
Warum? Ein normales NAS hat kaum die Ressorcen für zfs und dedupe. Und
btrfs bleibt Wunschdenken bei Fertig-NAS-Büchsen.
Die beschriebene blockbasierte Replikation von QNAP basiert auf ZFS, implementiert in deren Betriebssystem "QTS hero". Gibts aber wohl nicht für die kleinsten Boxen.
Um mal eines Klarzustellen, nicht das sich das irgendwie falsch festgesetzt oder ich falsch formuliert habe: Die VM und Container Images SIND Snapshots der laufenden VM oder Container. Diese werden aber nur an einer Stelle gespeichert, ich möchte aber natürlich auch eine externe Kopie zur Verfügung haben. Es geht hier um die Kopien der Backups.
Nicht das manche denken ich will mit rsync Backups der VM oder Container machen, darum geht es natürlich nicht. ☺️
Davon ging ich aus. Also von Offline-Kopien der VM Container-Dirs. Und diese Offline-Kopien sollen repliziert werden. Die von mir oben genannten Snapshots beziehen sich auf das Filesystem, auf dem diese Offline-Kopien liegen, nicht auf jenen Snapshot-Begriff, dem man im Virtualisierer begegnet.
Nur ist das beileibe nicht der einzige Weg, VMs sinnvoll zu sichern. Es gibt andere Wege, die sie auch online sichern können. So eine Replikation auf Basis von ZFS/btrfs lässt sich nämlich auch auf das Filesystem anwenden, auf dem die Live-Container liegen. Zumal das den Platzbedarf der 1+7+4-fachen Speicherung eines Containers zunächst einmal den von einem einzigen Container macht, plus zwischenzeitliche Änderungen.
Okay, es kann ja manchmal doch so einfach sein :-D
es gibt auch delete-before,delete-after und delete-during dazu noch erweitert delete-excluded in kombination mit exclude-from-file oder exclude.
Für inkrementelle Backups benutze ich rsnapshot, ist quasi ein kleines verwaltungssystem für rsync das einem die ganze umbennenerei wie auch weekly,monthly etc. abnimmt.
Da muss man dann kaum noch etwas Scripten ausser der Config in /etc/
