Webspace Backup Skript

tux sucksIch hatte ja neulich bereits eine Möglichkeit zum Backup eures Webspace auf den heimischen Computer und dessen regelmäßige Ausführung mittels cron gezeigt. Diese Lösung ist allerdings in mehrerer Hinsicht nicht optimal:

  • es wird jedes Mal alles komplett übertragen, nicht nur die geänderten Daten
  • kein Backup Archiv, also 'nur Backup von gestern' anstatt Backup von den letztn 7 Tagen

Deshalb habe ich mich mal mit meinen begrenzten Fähigkeiten in Sachen shell-scripting hingesetzt und ein wenig gestrickt. Das Produkt ist zwar noch nicht komplett ausgereift, aber es funktioniert (zumindest meistens 😉 ).

Vorraussetzungen dafür sind:

  • rsync (sollte bereits installiert sein)
  • curlftpfs (Installation mit 'apt-get install curlftpfs' unter (K)Ubuntu)

Das Skript tut das folgende:

  • Backup der geänderten Daten des FTP-Verzeichnisses mit rsync an euren Backup-Lieblingsplatz
  • Archiv mit Kopien eures Webspace der letztem 7 Tage in den Ordnern 'daily.1' bis 'daily.7'
  • Platzsparende Aufbewahrung durch Hard-Links

Installation:

Zuerst mal installieren wir curlftpfs:

sudo apt-get install curlftpfs

Herunterladen des Skriptes (Rechtsklick -> Ziel speichern unter)

Kopiert das Skript an einen für euch geeigneten Platz (bei mir /home/user/bin)

Ändert die folgenden Zeilen im Skript nach euren Bedürfnissen:

##############
#Konfiguration
##############

#Pfad zum Backupverzeichnis, ohne '/' am Ende
backdir=/path/to/backup
#Adresse des FTP-Servers
ftpaddr=ftpserver.de/pfad/zu/den/Daten
user=benuzername
pw=passwort
#Temporaeres Verzeichnis (muss nicht geaendert werden)
tempdir=/tmp/ftpbackup$(date +%F-%H%M%S)/

#############################

Speichert die Datei, macht sie mit einem chmod +x ftpback.sh ausführbar und testet ob es funktioniert:

sudo ./ftpback.sh ##sudo ist vorerst nötig um das FTP-Verzeichnis ein-/auszuhängen

Falls das ganze ohne Fehler durchläuft sollte am Ende etwas wie

sent 109673610 bytes received 113604 bytes 78168.18 bytes/sec
total size is 129370567 speedup is 1.18
Uebertragen

stehen. Danach könnt ihr das Skript wie in meinem Cron-Artikel beschrieben regelmäßig starten lassen.

Falls irgendetwas schieflaufen sollte, (was es hier nach etlichen Testläufen mit versch. Servern nicht getan hat) bitte kurze Rückmeldung an mich (am besten den Output der Konsole anhängen und an zero 'at' zeroathome 'dot' de). Leider kann ich für etwaige Schäden, die entstehen könnten, nicht haften.

Geplant für die nächste Version (when it's done 😉 ):

  • ausschließen von Dateien und Ordnern
  • überprüfen des freien Platzes der Festplatte

Was fällt euch dazu ein? Was kann man verbessern, wo sind grobe Fehler oder Optimierungsmöglichkeiten?

Da das mein erster shell-script Versuch ist bin ich für alle Vorschläge offen!!

12 Gedanken zu „Webspace Backup Skript

  1. vienna22

    Eben ausprobiert (noch ohne cron)… läuft wie am Schnürchen 🙂

    Das Script braucht zwar erheblich länger als ftpmirror was aber egal ist weil dafür die CPU-Auslastung noch um 1/4 geringer ist und daher den „normalen Dienstbetrieb“ nicht beeinträchtigt 😉

    Noch ein Vorteil: Aufgrund der Hardlinks benötigt das Backup über 40% weniger Speicherplatz!

    Beim ersten Mal werden jedoch gleich zwei Backups angelegt (daily.0, daily.1). Kann es sein, dass das Backup deshalb etwas länger dauerte?
    Etwas lästig ist, dass ein normaler User nicht einmal Leserechte hat (sehe nur Ordner und Unterordner) 🙁
    Werden eigentlich die originalen Dateirechte erhalten bzw. gespeichert (z.B. wenn ich die Dateien wieder herstellen muss)?

    Dank und Gruß aus Wien

  2. vienna22

    … Backup von heute morgen hochschieben, nach zwei Minuten ist die Sache erledigt.

    …war das Hauptargument für ftpmirror, quasi deinem gedanklichen Ausgangspunkt zu diesem Skript.
    Gilt das immer noch bzw. wie funktioniert der umgekehrte Weg?
    Das wäre vielleicht einen kleinen Artikel wert – außer ich bin der einzige Unwissende 😉

  3. zero

    Hallo Günter,

    beim ersten Durchlauf des Skriptes wird zuerst dein komplettes FTP-Verzeichnis „heruntergeladen“. Das dauert je nach Größe und Geschwindigkeit(Wobei ich nicht weis wie performant curlftpfs ist, jemand ne Ahnung?). Das Herunterladen erfolgt bei jedem Aufruf in daily.0, dann wird daily.7 (also das älteste Backup) gelöscht und alle anderen (daily.1-daily.6) nach oben verschoben und daily.0 nach daily.1 kopiert (Hard-Links), deshalb zwei Ordner beim ersten Durchlauf.

    Das mit den Leserechten ist im Moment noch suboptimal, mal sehen ob ich da was machen kann, die Rechte der heruntergeladenen Dateien sollten dank rsync erhalten bleiben.
    Um die Daten wieder zurückzuspielen, einfach den Inhalt des gewünschten Tages (daily.1-daily.7) per FTP-Programm auf den Server zurückspielen, aber mal sehen vielleicht bastel ich noch ein „Restore“ Skript, bringt aber glaube ich keinen Nennenswerten Vorteil, aber ich lass mich gerne Überzeugen…
    Freut mich das es funktioniert!! Weitere Rückmeldung wird freudig erwartet!

  4. Pingback: Linux-Benutzung » Re: Linux ist Teufelswerk, war Re: Linux wird sterben….. - Debatte um Linux im Bundestag verschärft…

  5. dz

    hallo,

    kann ich dein skript auch umgekehrt verwenden, also von lokal auf webspace sichern?

    lg,
    daniel

  6. Thomas Trueten

    Hallo,
    erst mal danke für das Script!
    Prinzipiell läuft es, ich bekomme jedoch folgende Fehlermeldungen:

    (…)
    sent 1403035262 bytes received 1386983 bytes 76692.00 bytes/sec
    total size is 1537456273 speedup is 1.09
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1058) [sender=3.0.5]

    Was nun?

  7. zero

    @Thomas: da sind wohl ein paar Dateien nicht übertragen worden…am besten schaust du dir den Output mal genauer an, er listet ja alles an Dateien auf beim Übertragen…da solltest du sehen welche Dateien den Fehler verursachen.
    am einfachsten haust du dir mit

    sudo ./ftpback.sh > output.txt

    das ganze in eine Datei, die du dann nach dem Durchlauf in Ruhe durchsuchen kannst.

  8. vizzy

    danke fuer den tipp mit curl, ledier hat die sache, zumindest unter debian lenny stable einen haken, es koennen keine files >2gb kopiert werden, da bricht curl ab und hinterlaesst datenschrott. das kann wenn man es als backup einsetzen will durchaus fatale folgen haben… 😉
    am besten vorher testen ob das aktuelle system ein buggy curl hat oder nicht. curl wuerde ich auf jedenfall nie in einer produktiven umgebung empfehlen, zu viel alphacode.

  9. zero

    Freut mich zu sehen, dass das gute Stück noch Verwendung findet, ist ja doch schon ein paar Tage alt 🙂

  10. mario

    hi,

    das script ist genau das was ich suche, leider kann man es nicht mehr herunterladen, gibts das vielleiht noch irgendwo?

    grüße

Kommentare sind geschlossen.