Die Historie des Wikis zeigt mir, daß sich bereits einige Forengurus mit Backupscript beschäftigt haben.

Folgender Artikel http://www.halfgaar.net/backing-up-unix brachte mich auf die Idee, mal in unser Wiki zu schauen, ob da alles zum Besten bestellt ist.

Dabei frage ich mich, wieso 7z verwendet wird, und nicht bzip2.
Ist 7z schneller oder komprimiert es besser als bzip2?

Der Vorteil von bzip2 ist, daß man es gleich in tar integrieren kann:

echo ...
...
tar -cp -f $TEMP_FILE $SOURCE
echo -- Komprimiere backup-$DATE.tar mit 7z
7z a -t7z $TEMP_ZIP $TEMP_FILE
...

würde zu

tar -cjpf $BACKUP_DIR/backup-$DATE.tar.bz2 $SOURCE

Neben dem kürzerem Kommando hat bz2 den Vorteil ein klassisches Linuxtool zu sein, so daß es auf einer LiveCD, von der man die Wiederherstellung starten will, eher vorhanden ist (ungeprüfte Annahme), daß ein User eher versucht eine Zeile zu verstehen, als 16 Zeilen, und daß mangelnder Festplattenspeicher nicht so schnell zu einem Problem wird.

Den Zweck des temporären Verzeichnisses, das gelöscht und dann neu angelegt wird, verstehe ich nicht, und auch nicht*, daß das alles in $HOME stattfindet, wodurch die Gefahr besteht, daß jmd. die zu sichernden Ordner so modifiziert, daß das Backupverzeichnis selbst Teil der Sicherung wird.

*) Wahrscheinlich um das Anlegen eines Ordners, in dem der User Schreibrechte hat, zu vermeiden - was aber ohnehin problematisch wird, wenn man nicht mit sudo sichert, aber /etc etc. auch zu sichern vorhat.

Anfangs dachte ich, das alte Backup wird gelöscht, bevor das neue erzeugt wurde, aber das kommt nur durch die intensive Verwendung temporärer Files.

Bevor ich aber die Arbeit anderer hinwegfege höre ich mir lieber an, ob ich was übersehen habe.

Die Historie des Wikis zeigt mir, daß sich bereits einige Forengurus mit Backupscript beschäftigt haben.

genau, du hast vollkommen Recht. Der Artikel ist alles andere als gelungen. Der von dir verlinkte Artikel ist weitaus empfehlenswerter,....
7z bietet zwar gute Kompression, ist aber verdammt langsam und lässt sich nicht vernüftig durch eine Pipe jagen. Für Backup-Zwecke daher ungeeignet, da eventuell eine temporäre tar-Datei erstellt werden muss (im Falle des vorgestellen Backupscripts liese sich das aber wohl sogar vermeiden,....)
Und dann macht er noch einen Backup von „$HOME/Bilder“ - jpeg Bilder lassen sich kaum weiter vernünftig packen, aber 7z verschwendet natürlich trotzdem Rechenzeit wie verrückt.
“dar“ ist für die meisten Fälle wohl besser geeignet. Man kann angeben, dass bestimmte Dateien nicht weiter gepackt werden sollen und die Dateien werden nur einzeln gepackt (nicht ein komplettes Tar-Archiv), was enorme Vorteile hat, wenn die Backup-Datei selbst etwas beschädigt werden sollte,.... Zudem kann es differentielle Backups und und und,…
Und wenn schon „tar“, dann wenigstens mit bzip2, gzip oder etwas anderem, bewährten,…

Das folgende Paket muss installiert werden ^[1]:
p7zip (universe ^[4])

Hier liegt der Fehler. Es gibt bestimmt 1000 tolle Programme für jedes Problem. Wenn meine Installation jedoch ein Standardtool selbst anbietet, werde ich nie irgendetwas anderes installieren. Besonders bei einem Backup kann es kritisch sein. Denn unter Umständen habe ich nur eine Live-CD ohne Internet und dann greife ich lieber auf tar, gzip usw. zurück.
Genauso wenig verlasse ich mich auf eine funktionstüchtige grafische Oberfläche oder einen alternativen Editor. Im Zweifelsfall muss ich ein System von Freunden administrieren, wo das ganze Zeug gar nicht existiert. Im übrigen auch ein Grund warum ich keine eigenen ALIAS-Einträge vornehme.

Gefällt mir auch nicht besonders, der Artikel. Kritik an der Verwendung eines exotischen Packprogramms um ein paar Prozent mehr Komprimierung zu erzielen, wurde ja schon geäußert. Auch der Grund, warum überhaupt ein Temp-Verzeichnis benutzt wird, bleibt im Dunkeln. Und zu guter Letzt sehe ich keinen Sinn darin, das Backup-Verzeichnis vor jedem Backup komplett zu löschen.

Zur Rettung der Ehre der „Forengurus“ ist eigentlich nur zu sagen, dass die Änderungen alle formeller Natur waren, also wahrscheinlich keiner sich wirklich mit dem Inhalt beschäftigt hat. Von wem der Artikel ist, kann man ja leider nicht nachvollziehen, da zu dem Zeitpunkt das Wiki defekt war und statt dem Benutzernamen den Hostnamen des Bearbeiters gespeichert hat.

Wenn das hier die Wikipedia wäre, könnte man ja einen Löschantrag stellen. :twisted:

P.S.: Ich setze erstmal ‚nen Link auf diese Diskussion da rein.

Dann möchte ich mal beantragen, dass der Artikel vollständig gelöscht wird. Es handelt sich in meinen Augen um ein Programm, welches nicht den Sinn des Wikis erfüllt, da es sehr speziell ist.
Auch ich habe ein sehr schönes Backupscript (Perl), welches jedoch per RSYNC (bzw. RSYNC über SSH) arbeitet, ein Datum berechnet und inkrementell die Daten sichert. Aber veröffentlichen würde ich es im Wiki auch nicht.

Neben der Löschung von „backupscript“ wäre es schön, wenn jemand einen Artikel „Backup“ anlegen würde. In diesem Artikel sollten Gründe für ein Backup aufgeführt werden, vielleicht grundlegende Konzepte erklärt werden und z.B. Verweise auf Packprogramme eingearbeitet werden. Spezielle Lösungen führen wohl zu weit.

uname hat geschrieben:

Dann möchte ich mal beantragen, dass der Artikel vollständig gelöscht wird.

Ich werde mal was in die Wege leiten. Wenn ich einfach so was lösche, kriege ich Ärger.
uname hat geschrieben:

Auch ich habe ein sehr schönes Backupscript (Perl), welches jedoch per RSYNC (bzw. RSYNC über SSH) arbeitet, ein Datum berechnet und inkrementell die Daten sichert. Aber veröffentlichen würde ich es im Wiki auch nicht.

Wenn du das nicht unbedingt als Geheimnis bewahren willst, kannst du es ja vielleicht unter Skripte einstellen.
uname hat geschrieben:

Neben der Löschung von „backupscript“ wäre es schön, wenn jemand einen Artikel „Backup“ anlegen würde. In diesem Artikel sollten Gründe für ein Backup aufgeführt werden, vielleicht grundlegende Konzepte erklärt werden und z.B. Verweise auf Packprogramme eingearbeitet werden. Spezielle Lösungen führen wohl zu weit.

Einen umfassenden Hintergrundartikel über Backups gibt es bereits auf Wikipedia: Backup. Einen besseren werden wir hier wohl nicht hinkriegen. Ich hab aber mal Packprogramme in Sicherheit#Sicherungskopien verlinkt. Vielleicht findet sich ja noch jemand, der einen kurzen Übersichtsartikel „Backups für Einsteiger“, oder so ähnlich, schreibt, der dann auf den Wikipedia-Artikel, Sicherheit#Sicherungskopien, und einige vorbildliche Wiki-Artikel aus diesem Bereich verlinkt. So in der Art von Mailserver Einführung.

otzenpunk hat geschrieben:

uname hat geschrieben:

Dann möchte ich mal beantragen, dass der Artikel vollständig gelöscht wird.

Ich werde mal was in die Wege leiten. Wenn ich einfach so was lösche, kriege ich Ärger.

Mit ‚hinwegfegen‘ meinte ich eigentlich nicht den ganzen Artikel, sondern nur die wesentlichen Inhalte.

Generell halte ich es schon für gut, auch eine Skriptlösung anzubieten, die der User anpassen und ausbauen kann.

Diese würde ich aber so gestalten, daß sie die diskutierte Kritik berücksichtigt, und wesentliche Teile des Systems sichert.

Die anderen Backuptools scheinen ja auch alle ihre Tücken zu haben:
- partimage: 2 GB - Warnung
- sbackup: regexp und chmod 700 - Warnung
- rsnapshot: eignet sich nicht für Komplettsicherungen
- rsync: nur die Kritik des o.g. Artikels: http://www.halfgaar.net/backing-up-unix#rsync_example

sonst wäre ein Artikel zur Sicherung mit tar entbehrlich.

@otzenpunk: „In die Wege leiten“ - heißt das, Du oder jmd. anderes arbeitet bereits an einer Verbesserung?

user unknown hat geschrieben:

Mit ‚hinwegfegen‘ meinte ich eigentlich nicht den ganzen Artikel, sondern nur die wesentlichen Inhalte.

Generell halte ich es schon für gut, auch eine Skriptlösung anzubieten, die der User anpassen und ausbauen kann.

Wäre es dann aber nicht besser, so einen Artikel und ein zugehöriges Skript von Grund neu zu schreiben? Ich meine so geniale Ideen sind da ja eh nicht drin, dass man da unbedingt was übernehmen muss. Außerdem würde ich den dann als neuen Unterartikel zu Skripte sehen wollen. Unter Sicherheit verlinken kann man ihn ja trotzdem.
user unknown hat geschrieben:

@otzenpunk: „In die Wege leiten“ - heißt das, Du oder jmd. anderes arbeitet bereits an einer Verbesserung?

Nein, das heißt ich hab mal eine Anfrage ans Wiki-Team gestellt, was die davon halten.

Ja - Struktur und Name des Artikels hätte man übernehmen können.
Ich bin nicht so wikifirm, eine Seite von Scratch zu schreiben.

Wenn einer die Lust und Zeit hat, die Seite zu bearbeiten darf er gerne anfangen. Für erste Fragen könnt ihr euch das durch lesen.

user unknown hat geschrieben:

Ich bin nicht so wikifirm, eine Seite von Scratch zu schreiben.

Bullshit, einfach drauf los schreiben kann jeder Notfalls nimmst du unsere Schnellstartvorlage, die du erhältst wenn du auf der Startseite eine neue Seite anlegst.

gruß
Ixel

Hallo!

Ich habe den Artikel überarbeitet.
Habe

tar -cjpf $BACKUP_DIR/backup-$DATE.tar.bz2 $SOURCE

übernommen, weil es viel einfacher ist als erst p7zip zu installieren.

Das Script ist nun viel kürzer und funktioniert genauso gut

Gruß, sIc

[edit]

Ich habe das „Fehlerhafte Anleitung“ entfernt, ich hoffe das war nicht zu voreilig…

Gut.
Ich bin über ein geschwätziges Vorwort nicht hinausgekommen, und hatte zuletzt nicht die Muße, an meinem Text weiterzuarbeiten.

Dennoch will ich 3 Punkte zur Sprache bringen, die mich noch stören (ohne den Text um den Code aufmerksam gelesen zu haben).

1. Date
In den Datumsstring würde ich Stunde-Minute-Sekunde mit aufnehmen.
Szenariio: Man hat ein Backup erstellt, und startet aus Versehen ein zweites. Man merkt‘s, und bricht das zweite ab, das das erste bereits überschrieben hat, aber jetzt auch gelöscht wird. Folge: Man hat keins mehr.
Mehr als ein Backup pro Sekunde wird aber niemand machen.

2. echo - echo - echo.
Die Silence is golden Regel wird ohne Not verletzt.
Hier wird sie erläutert - ein sehr empfehlenswertes Buch online, aber bringt am besten 4 Stunden Zeit mit:
http://www.catb.org/~esr/writings/taoup/html/ch11s09.html

3. Das Löschen alter Backups war vormals soweit ich mich erinnere auf temporäre Zwischendateien beschränkt.
Jetzt ist es völlig widersinnig.

Da ich der Meinung bin, daß alle 3 Punkte eine klare Verbesserung sind, habe ich sie durchgeführt, auch wenn ich noch nicht insgesamt zufrieden bin - aber dafür ist im Moment leider keine Zeit.

tar -cjpf $BACKUP_DIR/backup-$DATE.tar.bz2 $SOURCE

Warum nutzt Du den Parameter „j“:

-j, --bzip2
              filter archive through bzip2, use to decompress .bz2 files.  WARNING: some previous versions of tar used option
              -I  to  filter through bzip2.  When writing scripts, use --bzip2 instead of -j so that both older and newer tar
              versions will work.

Ich würde eher den Parameter „z“ nutzen, aber wohl eine Ansichtssache.

   -Z, --compress, --uncompress
              filter the archive through compress

Für „root“ kannst Du auf den Parameter „p“ im übrigen verzichten:

-p, --same-permissions, --preserve-permissions
              ignore umask when extracting files (the default for root)

Ich nutze dann noch „v“:

-v, --verbose
              verbosely list files processed

Also insgesamt

tar cvf $BACKUP_DIR/backup-$DATE.tar  $SOURCE
tar cvzf $BACKUP_DIR/backup-$DATE.tar.gz $SOURCE
tar xvf $BACKUP_DIR/backup-$DATE.tar  
tar xvzf $BACKUP_DIR/backup-$DATE.tar.gz  

a) bzip2 komprimiert besser u. schneller als bzip.
b) -p, …ignore umask when extracting files (the default for root)
Beim Extrahieren kann man auf p verzichten, sofern man root ist.
Ich komprimiere aber, und bin nicht immer root.
c) -verbose: Siehe Rule of Silence.

uname hat geschrieben:

Ich würde eher den Parameter „z“ nutzen, aber wohl eine Ansichtssache.

   -Z, --compress, --uncompress
              filter the archive through compress

-z und -Z sind aber zwei unterschiedliche Optionen. -Z benutzt das alte Unix-Compress, dass nun wirklich niemand mehr verwendet. -z benutzt gzip. In Skripten würde ich wahrscheinlich auch eher -z bevorzugen, weil bzip2 nicht immer standardmäßig installiert ist, aber anscheinend ist bzip2 bei Ubuntu auch in der Minimal-Installation enthalten, weswegen das in diesem Fall egal ist.