staging.inyokaproject.org

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.

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.

Zottel83 schrieb:

...sollte es eigentlich möglich sein, zu ermitteln welches davon das älteste ist, aber ich komme nicht drauf wie ich das anstelle.

Ja, das geht relativ einfach und ich halte das auch für einen möglichen Weg.

1. sucht alle Files, jünger als 3 Tage, einschließĺich Unterverzeichnisse

2. sucht alle Files, älter als 3 Tage, einschließĺich Unterverzeichnisse

3. sucht alle Files, älter als 3 Tage, aber keine Unterverzeichnisse

4. sucht alle Files, älter als 3 Tage, aber keine Unterverzeichnisse, löschen der gefundenen Dateien

1
2
3
4

find /backuppath -type f -mtime -3 -ls
find /backuppath -type f -mtime +3 -ls
find /backuppath -maxdepth 1 -type f -mtime +3 -ls
find /backuppath -maxdepth 1 -type f -mtime +3 -exec rm '{}' \;

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.

Nur als kurzer Hinweis:

Man sollte find nicht mit "-exec rm" verwenden, sondern -delete. Das ist lesbarer, schneller und weniger fehleranfällig...

Uuups... sorry... missverständnis.... deshalb gelöscht. -delete ist sicher der bessere weg.

Doc_Symbiosis schrieb:

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.

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

😛

Zottel83 schrieb:

Doc_Symbiosis schrieb:

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.

Ja, unbedingt.

Den Namen der ältesten Backup-Datei solltest Du dann so bekommen:

Oldest=$(ls backup_*.tar.gz | head -1)

Die Ausgabe von ls zu verarbeiten ist keine gute Idee (siehe die Links auf meiner Nutzerseite).

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?

Zählen ist einfach:

1
2
3
4
5

count=0

for f in "/ordner/fuer/backups"/backup_date*.tar.gz; do
  [ -f "$f" ] && count=$((count + 1))
done

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 find löschen:

1

find "/ordner/fuer/backups" -type f -name 'backup_date*.tar.gz' -mtime +3 -delete

Aber für Backups gibt es bereits reichlich fertige Lösungen. Ein Nachteil der Variante mit tar ist z.B., dass Du unveränderte Dateien immer wieder mit einpackst. Das kannst Du eleganter mit rsync machen, das unveränderte Dateien per Hardlink speichern kann (= nur ein Mal Plattenplatz verbraucht). Oder - wenn der Rechner einen graphischen Desktop hat und keine Server-Edition ist - Du nimmst gleich backintime, das per Cron und als Skript laufen kann. Von Borg-Backup habe ich auch schon Gutes gelesen.

rklm schrieb:

Ein Nachteil der Variante mit tar ist z.B., dass Du unveränderte Dateien immer wieder mit einpackst. Das kannst Du eleganter mit rsync machen, das unveränderte Dateien per Hardlink speichern kann (= nur ein Mal Plattenplatz verbraucht). Oder - wenn der Rechner einen graphischen Desktop hat und keine Server-Edition ist - Du nimmst gleich backintime, das per Cron und als Skript laufen kann. Von Borg-Backup habe ich auch schon Gutes gelesen.

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.

Zottel83 schrieb:

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.

Genau dabei kann rsync unveränderte Dateien mit denen seit einem vorherigen Stand nicht geänderten verlinken. Siehe Option "--link-dest=DIR".

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

$ mkdir -p source/data backup
$ date >source/data/file-1
$ date >source/data/file-2
$ rsync -aq source/ backup/1/
$ find backup/
backup/
backup/1
backup/1/data
backup/1/data/file-1
backup/1/data/file-2
$ date >|source/data/file-2
$ rsync -aq --link-dest ../1 source/ backup/2/
$ find -exec ls -d1i {} +
1203924 .
1203927 ./backup
1203934 ./backup/1
1203935 ./backup/1/data
1203936 ./backup/1/data/file-1
1203937 ./backup/1/data/file-2
1203939 ./backup/2
1203940 ./backup/2/data
1203936 ./backup/2/data/file-1
1203942 ./backup/2/data/file-2
1203925 ./source
1203926 ./source/data
1203932 ./source/data/file-1
1203933 ./source/data/file-2

Zeile 18 und 22 zeigen dieselbe Inode-Nummer, während 19 und 23 verschiedene zeigen.

BackInTime nutzt dieses Feature von rsync ebenfalls.

Mit tar werden die Dateien jedenfalls gleich komprimiert was ja mit rsync auch nicht passiert.

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 tar besser. (Übrigens würde ich dann nicht gzip sondern bzip2 für die Komprimierung nehmen, siehe tar-Option "j".)

Oder Du nimmst gleich BorgBackup und dann hast Du Komprimierung und Deduplizierung auf Kosten eines speziellen Speicherformats, das nur Borg lesen kann.

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 😉

Mal ein konkretes Beispiel: ich nutze BackInTime und habe fünf Backups:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ ls -1
20190802-164317-667/
20190905-232115-768/
20190910-184337-463/
20190920-235432-134/
20191010-084921-976/
last_snapshot@
$ du -sh last_snapshot/
262G	last_snapshot/
$ du -sh .
292G	.

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.

Zottel83 schrieb:

Also ich verstehe das jetzt so, dass Backup Nr. 2 nur noch die Daten beinhaltet, die sich seit dem ersten Backup geändert haben,

Nein, alle.

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?

Nein, die Dateiinhalte bleiben da, bis die letzte Referenz (also Verzeichniseintrag) gelöscht wird. Das ist ein Standardfeature von Dateisystemen; das kann sogar NTFS.

2. Wie stellt man im Ernstfall dann solche, über mehrere Backups verteilten Dateien wieder her?

Ganz normal mit beliebigen Tools, die Dateien kopieren können.

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 😉

Ja, spricht ja nix dagegen. Man kann halt auch von den bestehenden Lösungen lernen. Ich z.B. habe diese rsync-Option erst durch BackInTime kennengelernt. ☺

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 ^^

Junction Points und Hardlinks sind zwei unterschiedliche Dinge.

Ein Junction Point unter Windows bzw. NTFS entspricht am ehesten einem Mountpoint oder mount --bind in Linux, wobei es da noch Einschränkungen gibt. Du hast also ein Verzeichnis und hängst ein anderes Dateisystem/Verzeichnis an dieser Stelle ein.

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 ls -l recht gut überprüfen. Die Spalte vor dem Besitzernamen enthält genau diese Information:

$ 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:

$ rsync -aq --link-dest ../1 source/ backup/2/

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. ☺

Cranvil schrieb:

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. 🙄

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.

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).

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.)

Du kannst das mit ls -l recht gut überprüfen. Die Spalte vor dem Besitzernamen enthält genau diese Information:

Mit Option "-i" kann man dann auch noch die Inode-Nummer sehen.

Ich nehme hier eine Zeile aus rklms Beispiel. rklm schrieb:

$ rsync -aq --link-dest ../1 source/ backup/2/

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.

Genau!