staging.inyokaproject.org

Du hast ./ vergessen 😉

./backup_ext3.sh

so sollte es gehen

Hallo!

Ich habe das Programm gestern das erste mal gestartet und heute ein zweites mal. Mir scheint, dass auch beim zweiten Speichern eine Vollsicherung durchgeführt wurde. Auf meiner externen Festplatte habe ich nun zwei Verzeichnisse 090501 und 090502 die beide über 9 GB groß sind.

Ich hatte erwartet, dass beim zweiten Durchlauf nur ein inkrementelles Backup erstellt wird. So sollte es doch eigentlich auch sein, oder? Hat jemand eine Idee, warum bei mir ein Voll-Backup durchgeführt wurde?

Grüße, Gerald

Chuck77 schrieb:

Ich hatte erwartet, dass beim zweiten Durchlauf nur ein inkrementelles Backup erstellt wird. So sollte es doch eigentlich auch sein, oder? Hat jemand eine Idee, warum bei mir ein Voll-Backup durchgeführt wurde?

So wie das Skript funktioniert, sollte dort auch nur ein inkrementelles Backup durchgeführt worden sein. Der Rest wird durch Hardlinks simuliert. Die Verzeichnisse sind also beide 9 GB groß, aber da die meisten Verzeichniseinträge auf dieselben Datenblöcke verweisen, sollten sie gemeinsam nur 9 GB + x belegen. (Kannst du mit df -h überprüfen.)

Stimmt! Es werden tatsächlich nur 9 GB + x verbraucht! Raffiniert! Danke!

Chuck77 schrieb:

Stimmt! Es werden tatsächlich nur 9 GB + x verbraucht! Raffiniert! Danke!

Du musst eben auch drauf achten, dass das Zieldateisystem hardlinks unterstuetzt.. dann sollte es kein Problem sein. Mit ls -li kannst du ueberpruefen, ob die Dateien in den einzelnen Sicherungen tatsaechlich auf die gleichen inodes verweisen (also ob es wirklich hardlinks sind).

Matthias

Mit ls -li kannst du ueberpruefen, ob die Dateien in den einzelnen Sicherungen tatsaechlich auf die gleichen inodes verweisen (also ob es wirklich hardlinks sind).

Alternativ zeigt der Befehl

stat dateiname

noch die Anzahl der Hardlinks unter "Links" an. Dort sollte dann eine Zahl größer "1" stehen.

Ich hoffe die neue Version gefällt. Habe mittlerweile mein Backup-Intervall auf 30 Tage gesetzt. Nun brauche ich auf meinem Server nicht mehr von Hand löschen.

Nachdem ich den SSH-Port meines VServers (Debian Lenny) von "22" auf einen anderen Port umgelegt hatte, habe ich gemerkt, dass mein Script gar nicht damit umgehen kann.

Habe es entsprechend aktualisiert, damit ich weiterhin meinen VServer inkrementell backupen kann.

Skripte/Backup mit RSYNC

Zur Info: Ich habe erfolgreich inkrementelle Backups mit einer NTFS-Partition als Ziel anlegen koennen. Die Windows-API stellt dafuer ab Win2000 Funktionen zur Verfuegung, welche von dem ln, welches mit Cygwin oder MinGW mitgeliefert wird, genutzt werden.

Sprich: fuehrt man dieses Skript unter Windows aus, funktioniert das inkrementelle Backup.

Ob ln unter Linux ueber ntfs-3g die entspr. API-Befehle nutzt, habe ich noch nicht getestet. Was haltet ihr davon, wenn wir unter dem Punkt Einschraenkungen eine Tabelle mit den getesteten Dateisystemen (und notfalls Zusatzinformationen) anlegen. HFS+ unterstuetzt z.B. hardlinks, trotzdem klappt rsync out-of-the-box nicht, da die Rechtevergabe per default idiotisch ist (unter /Volumes eingebundene Medien nutzen die Rechteverwaltung nicht, was dazu fuehrt, dass rsync immer eine Differenz feststellt).

EDIT1: Weitere Informationen:
Hard Link (Wikipedia)
NTFS Hard Links, Directory Junctions, and Windows Shortcuts

EDIT2: Ich kann jetzt bestaetigen, dass ntfs-3g die Hard Link Funktionen von NTFS nicht unterstuetzt.

Was haltet ihr davon, wenn wir unter dem Punkt Einschraenkungen eine Tabelle mit den getesteten Dateisystemen

Gerne, das Wiki lebt vom mitmachen. Trag es einfach entsprechend ein.

uname schrieb:

Gerne, das Wiki lebt vom mitmachen. [...]

Ich weiss 😉 Jenachdem, wieviel Zeit mir zur Verfuegung steht, bin ich auch sehr fleissig (vor 2 Jahren habe ich den kompletten WLAN-Bereich neugebaut). Ich mach mal ne kleine Tabelle fertig.

EDIT: Tabelle ist eingefuegt.

Ich habe das Skript unverändert installiert. Die Backups funktionieren einwandfrei.

Doch löscht es mir nicht automatisch die alten Versionen nach x Tagen.

Mein Eintrag unter den Variablen:

SOURCES="/home/firma/"
TARGET="/home/spiegel/sicher/"
LOGFILE="/home/firma/netrom/Wartung/log/backup.log"
EXPIREDAYS=14
RSYNC="--delete"

Hat jemand eine Idee, wo es haken könnte?

Danke schon einmal.

Das Skript ist darauf ausgelegt als root ausgefuehrt zu werden. Machste das auch?

mniess schrieb:

Das Skript ist darauf ausgelegt als root ausgefuehrt zu werden. Machste das auch?

Das wars. Ich war wohl als root angemeldet, habe aber nicht sudo vorangestellt. Man lernt halt nie aus.

Danke.

omike23 schrieb:

mniess schrieb:

Das Skript ist darauf ausgelegt als root ausgefuehrt zu werden. Machste das auch?

Das wars. Ich war wohl als root angemeldet, habe aber nicht sudo vorangestellt. Man lernt halt nie aus.

Danke.

Ok, wenn ich auf der Kommandozeile mit sudo das Skript ausführe ist alles in Ordnung. Es wird brav die alte Sicherung gelöscht.

Es funktioniert aber nicht, wenn ich es als cronjob ausführen lasse: Sicherung wird gemacht, aber nicht die alten Daten gelöscht.

Hier mein Eintrag in Crontab: (Es funktioniert auch nicht, wenn ich sudo weglasse.)

# m h dom mon dow user	command
0 8  * * * 	root   sudo /root/backup.sh

Etwas mit root per sudo auszufuehren ergibt keinen Sinn. sudo gibt dir ja gerade root-rechte. Sofern du die cronjobs mit "sudo crontab -e" editierst, handelt es sich um die root-cronjobs.. dort sollte auf keinen Fall sudo stehen.