Hallo, ich würde gerne in einem Skript verschiedene Ordner mit tar sichern und das Ganze regelmäßg mittels cronjob automatisch durchführen lassen. Jetzt wollte ich aber nicht nur ein Backup anlegen sondern es sollen immer mehrere existieren. Diese sollen nach dem folgenden Namensschema aufgebaut sein: backup_date +%d%b%Y
.tar.gz
Sagen wir es sollen immer 3 Backups bestehen, dann soll das Skript beim Start überprüfen ob schon 3 Backups bestehen und wenn ja, welches davon das älteste ist, dieses soll dann gelöscht und durch ein neues ersetzt werden.
Durch den Namenszusatz date +%d%b%Y
sollte es eigentlich möglich sein, zu ermitteln welches davon das älteste ist, aber ich komme nicht drauf wie ich das anstelle.
mehrere gleiche Backups
Anmeldungsdatum: Beiträge: 112 |
|
||||
Anmeldungsdatum: Beiträge: 4378 Wohnort: Göttingen |
Hm, also dein %b im date Kommando finde ich eher ungünstig dafür. Du solltest dafür eher rein numerische Namen verwenden, also z.B. date +"%Y%m%d" Damit ersparst Du Dir eine Menge Scherereien mit sprachabhängigen Monatsnamen und kannst die Dateinamen auch besser sortieren. Den Namen der ältesten Backup-Datei solltest Du dann so bekommen: Oldest=$(ls backup_*.tar.gz | head -1) Du musst natürlich noch Verzeichnisnamen oder so ergänzen. |
||||
Anmeldungsdatum: Beiträge: 603 |
Ja, das geht relativ einfach und ich halte das auch für einen möglichen Weg.
Den letzten Befehl nur mit großer Sorgfalt anwenden! Eine Alternative wäre es allerdings, den Backups kein Datum zu geben, sondern jeweils die Extension 1, 2 oder 3 anzufügen und die Backups sich selber einfach rotierend damit überschreiben lassen. Dann gibts immer 1 Backup und 2 Vorversionen, das Datum ist dabei irrelevant... außerdem sieht man's am Inode-Inhalt. |
||||
Anmeldungsdatum: Beiträge: 4378 Wohnort: Göttingen |
Nur als kurzer Hinweis: Man sollte find nicht mit "-exec rm" verwenden, sondern -delete. Das ist lesbarer, schneller und weniger fehleranfällig... |
||||
Anmeldungsdatum: Beiträge: 603 |
Uuups... sorry... missverständnis.... deshalb gelöscht. -delete ist sicher der bessere weg. |
||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 112 |
Hey danke erstmal, das war schon gnau das wonach ich gesucht habe. Ich bräuchte aber nochmal Hilfe. Wie lässt sich denn herausfinden wie viele Backups schon vorhanden sind, für den Fall dass sich noch andere Dateien als die Backups im Ordner befinden? Edit, hat sich erledigt, ich habe es gerade allein hinbekommen: #!/bin/bash count=$(find -iname backup_\*.txt | wc -l ) echo $count if [ $count -ge 3 ];then Oldest=$(ls backup_*.txt | head -1) echo $Oldest rm $Oldest #echo "$Oldest wurde gelöscht" fi 😛 |
||||
Projektleitung
Anmeldungsdatum: Beiträge: 12801 |
Ja, unbedingt.
Die Ausgabe von
Zählen ist einfach:
Schwieriger ist es, die älteste Datei zu ermitteln. Deutlich einfacher ist es, wenn Du einfach ein maximales Alter der Backups annimmst. Dann kannst Du nämlich die alten schön mit
Aber für Backups gibt es bereits reichlich fertige Lösungen. Ein Nachteil der Variante mit |
||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 112 |
Ich verstehe den Vorteil von rsync für denn Fall wenn ich ein Backup immer in ein und den selben Zielordner reinpacke. Da habe ich eine Zeitersparnis, weil nur die Dateien kopiert werden die sich verändert haben. Da ich hier aber ein Backup mehrmals vorhalte bzw. mehrere Versionen des Backups anlege, verstehe ich in dem Fall nicht worin der Vorteil von rsync liegen soll. Mit tar werden die Dateien jedenfalls gleich komprimiert was ja mit rsync auch nicht passiert. |
||||
Projektleitung
Anmeldungsdatum: Beiträge: 12801 |
Genau dabei kann
Zeile 18 und 22 zeigen dieselbe Inode-Nummer, während 19 und 23 verschiedene zeigen. BackInTime nutzt dieses Feature von
Das stimmt. Kommt halt darauf an: wenn Du viele ungeänderte Dateien hast oder die sehr groß sind, dann ist die Link-Methode effektiver. Wenn Du viele kleine Dateien hast und sich die auch noch ständig ändern, ist der Ansatz mit Oder Du nimmst gleich BorgBackup und dann hast Du Komprimierung und Deduplizierung auf Kosten eines speziellen Speicherformats, das nur Borg lesen kann. |
||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 112 |
Ah danke schonmal, auch wenn ich noch nicht weiß ob ich das auch so anwenden werde, ist es gut zu wissen dass dies möglich ist. Also ich verstehe das jetzt so, dass Backup Nr. 2 nur noch die Daten beinhaltet, die sich seit dem ersten Backup geändert haben, der Rest wird mit Hardlinks "aufgefüllt" Dabei kommen mir jetzt zwei Fragen in den Sinn: 1. Wie funktioniert das nun, wenn ich dann das älteste Backup lösche? Dann verweisen diese Links ja auf Daten, die nicht mehr vorhanden sind? 2. Wie stellt man im Ernstfall dann solche, über mehrere Backups verteilten Dateien wieder her? PS: mir ist schon bewusst dass es zu allem Möglichen eine vorgefertigte Lösung gibt, aber ich finde es in der Regel immer besser die Sachen selber umzusetzen und dabei etwas zu lernen, wie es ja jetzt auch schon geschehen ist 😉 |
||||
Projektleitung
Anmeldungsdatum: Beiträge: 12801 |
Mal ein konkretes Beispiel: ich nutze BackInTime und habe fünf Backups:
Wie man sieht, brauchen alle fünf Backups nur 30GB mehr als der letzte. Ich fahre die VMs allerdings auch nicht so oft hoch, so dass es bei den riesigen Dateien selten Änderungen gibt. Die Daten liegen auf einem BTRFS-Dateisystem mit Kompression, aber diese spart nur ungefähr 6GB. Ich finde an BackInTime gut, dass die Dateien in einem normalen Dateisystem liegen und man ohne Spezialtools reinschauen kann.
Nein, alle.
Nein, die Dateiinhalte bleiben da, bis die letzte Referenz (also Verzeichniseintrag) gelöscht wird. Das ist ein Standardfeature von Dateisystemen; das kann sogar NTFS.
Ganz normal mit beliebigen Tools, die Dateien kopieren können.
Ja, spricht ja nix dagegen. Man kann halt auch von den bestehenden Lösungen lernen. Ich z.B. habe diese |
||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 112 |
So nach ausgiebigen Tests kann ich sagen es stimmt. Ich kann so viele Backups erstellen wie ich will, solange sich nichts verändert nehmen neue Backups nicht mehr Platz weg. Leider verstehe ich nicht wie das funktioniert. Der Wiki-Artikel hilft mir nicht beim Verständnis. Ich kenne Hardlinks unter Windows als Junktionpoints, die wieHyperlinks auf Webseiten funktionieren. Wenn ich da denn Quellordner lösche, funktieren logischerweise die Links auch nicht mehr. Aber hier kann ich den Quellordner löschen und die Backups funktionieren trotzdem noch? Ich bin verwirrt ^^ |
||||
Anmeldungsdatum: Beiträge: 990 |
Junction Points und Hardlinks sind zwei unterschiedliche Dinge. Ein Junction Point unter Windows bzw. NTFS entspricht am ehesten einem Mountpoint oder Ein Hardlink unter NTFS entspricht konzeptionell einem Hardlink unter Linux - und das (nach kurzer Recherche) schon seit erstaunlichen 26 Jahren (Quelle 1, Quelle 2). Wer die Geschichte verfolgt hat oder sich die Artikel durchliest, wird wissen/feststellen, dass Microsoft die meisten dieser Jahre damit verbracht hat, das Feature nicht zu intensiv zu nutzen. 🙄 Hardlinks sind dagegen ein Dateisystemfeature, das auf der Trennung von Bezeichnung und Inhalt beruht. Wenn ich einen Namen habe, kann ich das Dateisystem fragen, ob es mir den Inhalt dafür liefern kann. Lege ich nun einen neuen Hardlink an, merkt sich das Dateisystem für die neue Bezeichnung, wo der (alte) Inhalt herumliegt, und zusätzlich setzt es in den Metadaten des Inhalts einen Zähler höher. Letzteres ist notwendig, damit das Dateisystem beim Löschen der einen Referenz auch weiß, ob der Speicher für den Inhalt selbst freigegeben werden kann (Zähler wechsel von 1 zu 0). Du kannst das mit $ touch datei1 $ ls -l datei* -rw-r--r-- 1 user group 0 18 Okt 22:02 datei1 $ ln datei1 datei2 $ ls -l datei* -rw-r--r-- 2 user group 0 18 Okt 22:02 datei1 -rw-r--r-- 2 user group 0 18 Okt 22:02 datei2 $ rm datei2 $ ls -l datei* -rw-r--r-- 1 user group 0 18 Okt 22:02 datei1 Ich nehme hier eine Zeile aus rklms Beispiel. rklm schrieb:
Das wichtige daran sind die drei Verzeichnisangaben: Eine für die Quelle (source/), eine für das Ziel (backup/2/) und eine zum letzten Referenzbackup (../1). Mit Hilfe von Quelle und Referenzbackup kann rsync bestimmen, für welche Dateien im Ziel Hardlinks erzeugt werden müssen. Ich hoffe, ich konnte das Konzept noch etwas verdeutlichen. ☺ |
||||
Projektleitung
Anmeldungsdatum: Beiträge: 12801 |
Ja, Microsoft ist besser, als viele denken. Es gibt sogar Softlinks. Aber die meisten kennen nur die .lnk-Links, die kein Dateisystemfeature sind, sondern auf einer höheren Ebene liegen (Explorer und Programme). Wo wir schon dabei sind: NTFS ist meiner Meinung nach ein recht gutes Dateisystem (mit Journaling!) - man denkt nur immer, es wäre langsam, weil die meisten Windows-Installationen on access Virenscanner haben usw.
Das ist halt das Entscheidende: Verzeichniseinträge sind immer Referenzen auf den Inode. Jeder Eintrag, der auf den Inode zeigt, ist gleichwertig. Und erst wenn der letzte gelöscht wurde, wird auch der Inode und damit der Dateiinhalt gelöscht. (Streng genommen ist es sogar noch etwas komplizierter, weil auch offene Dateideskriptoren in Prozessen mitzählen. Man kann also eine Datei auf der Platte haben, die von keinem Verzeichnis referenziert wird, so lange mindestens ein Prozess einen offenen Deskriptor auf diesen Inode hat. Erst, wenn der Prozess verschwindet, wird auch der Dateiinhalt gelöscht.)
Mit Option "-i" kann man dann auch noch die Inode-Nummer sehen.
Genau! |