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.
Stefan F. schrieb: > 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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Auch NTFS beherrscht Hardlinks Mag sein, aber die Software kann es micht. > Wer verwendet da freiwillig NTFS? Z.B derjenige, der das Medium auch unter Windows nutzen will. Oder derjenige, der es nicht umformatieren will.
(prx) A. K. schrieb: > 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.
Stefan F. schrieb: > 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.
(prx) A. K. schrieb: > 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.
900ss D. schrieb: > 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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Es reduziert nur den eigentlichen Kopiervorgang. OK, verstehe. Welche Tools beherrschen denn die Sicherung nur veränderter Blöcke?
900ss D. schrieb: > 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. Als Filesysteme können das mindestens ZFS und btrfs, da deren Snapshot-Verfahren direkt die Grundlage dafür bieten.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Im Kontext von VMs beispielsweise die darauf spezialisierte > Backup-Software von Nakivo Genau für VMs interessiert es mich. Aber eher im privaten Rahmen. (prx) A. K. schrieb: > 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.
900ss D. schrieb: >> 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.
:
Bearbeitet durch User
Andreas B. schrieb: > Parameter --delete? Okay, es kann ja manchmal doch so einfach sein :-D Lieben Dank euch allen!
(prx) A. K. schrieb: > 900ss D. schrieb: >> 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.
Drago S. schrieb: > Warum? Ein normales NAS hat kaum die Ressorcen für zfs und dedupe. Naja, diese deine Auffassung mag daher rühren, was für dich ein "normales" NAS ist... Meins kann jedenfalls btrfs und auch Deduplizierung... Und ja: es ist eine "Fertig-NAS-Büchse", wie du sie zu titulieren beliebst. Nur halt keine ganz kleine, billige...
Drago S. schrieb: > 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.
:
Bearbeitet durch User
Drago S. schrieb: > Nachdem rsync im Einsatz ist, werfe ich BorgBackup in den Raum. Also die > fehlende Deduplizierung auf Dateiebene. Yep, das verwende ich privat über WAN zu einem RasPi 3 mit HDD als Backup-Ziel. Allerdings ohne die VM-Images.
:
Bearbeitet durch User
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. ☺️
Beitrag #7436851 wurde vom Autor gelöscht.
Rene K. schrieb: > Es geht hier um die Kopien der Backups. 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.
:
Bearbeitet durch User
Rene K. schrieb: > 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
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.