Automatisches Backup des Filesystems

Hallo,

nach einem kleinen Problem (dessen Symptome zwar behoben, dessen Ursache aber immer noch nicht gefunden und behoben ist) würde ich gerne bis auf weiteres das Dateisystem meiner Contao-Installation (incl. aller Dateien, die meine Redakteure hochladen) täglich automatisiert sichern. Mit der Datenbank passiert dies über einen Cronjob und mySqlDumper sowieso schon lange. Es wäre ausreichend, wenn einfach das komplette Contao-Verzeichnis (ca. 1. GByte) gezippt auf den gleichen Server gelegt wird.

Normalerweise mache ich das manuell über den SSH-Client PuTTY, aber ich brauche eine automatisierte Lösung. Wie könnte das gehen?

Danke
HaPe

Ich nutze dazu ein PHP-Skript, welches ich über einen Cronjob aufrufe. Die Dateien werden gepackt und im Unterordner web des PHP-Skriptes abgelegt:

PHP-Code:

---

ini_set("max_execution_time",0); // Ausführungszeit auf unendlich

$Datum = date("Ymd-Hi",time());

system ("tar cfvz web/contao_system_modules_$Datum.tar.gz /kunden/xxx/system/modules/");
system ("tar cfvz web/contao_system_config_$Datum.tar.gz /kunden/xxx/system/config/");
system ("tar cfvz web/links_$Datum.tar.gz /kunden/xxx/admin/links/data/");
system ("tar cfvz web/schachbl_$Datum.tar.gz /kunden/xxx/SchachBL/");
system ("tar cfvz web/contao_templates_$Datum.tar.gz /kunden/xxx/templates/"); 


---

Schau Dir doch mal http://www.cyberkiko.com/page/ftpsync/ an. Auch über einen Task Scheduler aufrufbar.

Alternativ schreibe ich an dieser Stelle eigentlich immer, dass sich Webserver mit versionierendem Dateisystem (vulgo: ZFS unter FreeBSD) für Backupszenarien extrem auszahlen können. Das mag dann aber #Neuland sein.

Ich hatte immer Reoback benutzt http://reoback.sourceforge.net/. Weiß nicht, ob das mit neuen PHP-Versionen noch läuft, ansonsten hatte das gut funktioniert. Ein Script, welches du auf den Server legst, Einstellungen macht man in x.conf Dateien. Angesteuert habe ich das über einen Cronjob. Features: Incremental, Transfer auf anderen Server, Zustellung per E-Mail.

Der Cronjob sah so aus:
44 4 * * *
/var/www/XXX/html/cgi-bin/reoback/run_reoback.sh

Hallo,

@Frank: Im Prinzip ist das genau das, was ich gesucht habe. Allerdings legt mir das Script ein Backup an, dass exakt immer 64 MB groß ist. Das ist viel zu klein. Erwarten würde ich etwa 960 MByte. Möglicherweise ist das eine Limitation, die mir Strato auferlegt, wenn ein PHP-Script verwendet wird.

Ciao
HaPe

Zitat:

---

Zitat von HaPe

@Frank: Im Prinzip ist das genau das, was ich gesucht habe. Allerdings legt mir das Script ein Backup an, dass exakt immer 64 MB groß ist. Das ist viel zu klein. Erwarten würde ich etwa 960 MByte.

---

Meine Backups sind 22 MB und kleiner. Ich hatte auch schon mal mehr Verzeichnisse mit drin. Allerdings lief dann das Skript nicht durch. Und den Ordner files zu sichern macht eh keinen Sinn, da dieser mehr als 30 GB hat. Ich habe vom gesamten Web im Notfall aber eine lokale Kopie. Auch wenn die manchmal ein paar Wochen alt ist.

Ich glaube, das ist eine schlechte Idee, sich bei einem Hosting von Strato Arbeitsspeicher in der von Dir für ein verpackendes PHP-Script benötigten Grösse zu erhoffen. Wenn man es denn serverseitig machen möchte erscheint mir https://wiki.ubuntuusers.de/Skripte/...telles_Backup/ als ein besserer Startpunkt anstatt eines feedbacklosen Fünfzeilers.

Obendrein denke ich, dass es ebenfalls eine schlechte Idee sein könnte, sich den Webspace im Tagestakt mit Daten im Gigabytebereich volllaufen zu lassen.

Neben den von mir und Andreas genannten Optionen käme sicher noch ftpget für die Aufgabe in Frage.

Sorry, ich habe das jetzt oben nochmal korrigiert, Reoback ist ja überhaupt kein PHP-Programm und deshalb auch nicht abhängig von irgendeiner Version :o

Hallo,

Zitat:

---

Zitat von lucina

Ich glaube, das ist eine schlechte Idee, sich bei einem Hosting von Strato Arbeitsspeicher in der von Dir für ein verpackendes PHP-Script benötigten Grösse zu erhoffen [...] Obendrein denke ich, dass es ebenfalls eine schlechte Idee sein könnte, sich den Webspace im Tagestakt mit Daten im Gigabytebereich volllaufen zu lassen.

---

mein Wunsch ist, ein tägliches, automatisiertes Vollbackup der Website zu erstellen, so dass ich (anders als in meinem letzten Fehlerfall) einen funktionierenden Stand der Website sehr schnell wieder herstellen kann, ohne in inkrementellen Backups herum pfriemeln zu müssen. Das tägliche Vollbackup wird dann nicht mehr nötig sein, wenn ich wieder mehr Zutrauen zu dem Gesamtsystem (Provider, Contao, Betriebssystem, Webserver, Support, etc.) gefunden habe. Aber momentan ist dieses Vertrauen ziemlich dahin.

Was ich nicht explizit suche ist ein PHP Script, eine Alternative zu Strato, noch mehr fehleranfällige Scripte etc. Ich habe Webspace für etwa 30 Voll-Backups. Bevor ich diese brach liegen lasse, würde ich sie eben gerne nutzen. Ich hätte nicht gedacht, dass es heutzutage so schwer ist, ein vernünftiges (= einfaches, robustes, automatisches) Backup-Konzept für Verzeichnisse auf einem Webserver zu finden. Aber das Internet ist doch immer wieder für Überraschungen gut.

Wie gesagt: Mit einem SSH-Client funktioniert es völlig problemlos und es gibt hier auch keine 64 GByte Grenze. Nur muss ich das immer manuell anstoßen.

Ciao
HaPe

Liesse sich doch sicher via rsync mit einem Cronjob relativ einfach bewerkstelligen. Am besten zu einer Zeit, wo nicht allzuviel los ist.

Die Möglichkeiten hängen am Provider.
Bei All-Inkl. kann ich FTP- und Datenbankbackup auch in einem einfacheren Hostingpaket (ab PrivatPlus) einrichten:
http://all-inkl.com/wichtig/anleitun...ichten_97.html
http://all-inkl.com/wichtig/anleitun...tellen_83.html

Vom Cronjob gestartet läuft es zeitgesteuert automatisch ab. Man kann die Sicherung noch erweitern, indem man zum Schluss noch die gesicherten Daten auf einen anderen Server kopiert, um auch gegen Ausfall von Hardware geschützt zu sein.

Hallo,

Zitat:

---

Zitat von do_while

Bei All-Inkl. kann ich FTP- und Datenbankbackup auch in einem einfacheren Hostingpaket (ab PrivatPlus) einrichten:

---

okay ... aber ich bin weder bei All-Inkl. noch möchte ich ein FTP- oder ein Datenbankbackup machen. Das geht jetzt in die ganz falsche Richtung.

ich bin inzwischen zumindest schon so weit, dass ich den gewünschten Vorgang durch einen einzigen "klick" auf einen Desktop-Icon und ohne weitere Eingaben ausführen kann. Ist ja schon mal was.

Ciao
HaPe

Hallo HaPe,
richte dir einfach Reoback ein. Damit sollte das alles automatisiert (mittels Cron) funktionieren. Da das dann auch über Konsole läuft, sollte das eigentlich keine Probleme machen.
Ich hab sowas auch im Einsatz und das klappt recht gut.

Viele Grüße

Wenn du einen unixoiden Rechner wo hast den du für die Backups verwenden kannst (ich nehme an das Backup soll wo anders liegen als auf dem Webspace) schau dir unbedingt rsnapshot an.

Damit kannst du gemütlich per ssh und rsync Daten sichern und einfach angeben wie viele stündliche, tägliche, wöchentliche, ... Backups du vorhalten willst. Die DB sicherst du eh schon (vor dem rsnapshot Lauf) in eine Datei weg die rsnapshot dann auch sichern kann.

Strato besitzt doch für den normalen webspace bereits ein backupcontrol system, das den kompl. Webspace sichert.
Und ssh basierende crons sollten auch gehen.

Ich nutze unter anderem duplicity, welches auch inkrementielle backups macht, das zurückspielen ist simpel, wenn du inkrementielle backups nicht möchtest *verstehe gar nicht warum* lässt du eben einfach täglich ein full-backup erstellen.

Hallo,

interessant. Das hatte ich bislang noch überhaupt nicht auf dem Schirm. Ich werde mich mal informieren, ob das im einem Fall Sinn macht.

Generell empfinde ich allerdings ausgelagerte Sicherheits-Funktion aber als einen Widerspruch in sich. Das ist ungefähr so als ob man die Wartung des eigenen Herzschrittmachers an den meistbieteten eBay-Anbieter überträgt :eek:

Ciao
HaPe

Das Stichwort wäre 'Redundanz' - ich finde auslagern vollkommen sinnvoll.

(Das schreibe ich als diejenige, die mal bei der Firma aus dem Westerwald erlebt hat, wie sich Backups in Luft auflösten, weil das Zielsystem auf der selben defekten Festplatte wohnte wie das zu sichernde System - und die dann feststellen musste, das der Anbieter seiner vertraglichen Verpflichtung zu externen Kopien nicht nachgekommen war weil das entsprechende Script in den letzten 18 Monaten genau ein mal durchgelaufen war)

Von versteigern hat ja niemand geredet. Und von eBay schon gar nicht.

Ja, sowas passiert. Öfter als man denkt. Mein "bestes" Erlebnis war bei einem Ex-Arbeitgeber, wo nur alle paar Wochen von den Netzwerklaufwerken ein Vollbackup gefahren wurde und dazwischen täglich inkrementelle Backups. Dann gab es einen Plattencrash auf einem der Netzwerklaufwerke. Eine Diplomarbeiterin hatte ihren aktuellen Arbeitsstand dort (und leider nur dort) gespeichert, eine Woche vor Abgabetermin. Aber man hat ja ein Backup. Oder besser, man hätte eins gehabt, wenn man seitens des Rechenzentrums das tägliche inkrementelle Backup nicht jeden Tag mit dem neuen inkrementellen Backup überschrieben hätte :rolleyes:. So bekam sie nur eine mehrere Wochen alte Version ihrer Daten wieder.

Das war nicht lustig. Sie hat auf die harte Tour gelernt, dass man beim Backup sich nie nur auf andere verlassen sollte, sondern auch selbst regelmäßig Backups fahren sollte auf andere Datenträger. Und bei sehr wichtigen Daten am besten mehrere Backups auf verschiedene Datenträger. Selbst wenn das Rechenzentrum das alles korrekt gemacht hätte und auf mehrere verschiedene Festplatten. Auch ein Rechenzentrum kann mal abbrennen. Da ist es schon besser, wenn auch andernorts noch Backups existieren. Sie hat es damals noch zum Termin geschafft, aber sicher eine Menge Stress dabei gehabt, denn der Abgabetermin wurde nicht verschoben.

Hi,

die Archivierung der Backups (gerne auch verteil und gesichert gegen Vandalismus, Tsunamis, EMPs, Alien-Invasionen und aus dem Ruder laufende Kindergeburtstage etc.) steht in diesem Thread erstmal nicht zur Debatte, sondern die Handhabung des sog. "ersten Fehlerfalls", also dass der Verlust von Produktiv-Informationen zu beklagen ist und durch eine simple, automatisierte Prävention für Abhilfe gesorgt ist, sofern kein "zweiter Fehlerfall" eingetreten ist.

Ciao
HaPe

Was spricht dann gegen eine der mehr oder weniger komfortablen Lösungen? Bzw was macht denn der Button, auf den du nur noch klicken musst? Kann das ein Cronjob nicht? Schwer vorstellbar, wenn da nicht gerade ein Backup per FTP angestossen wird. Ich verstehe gerade irgendwie das Problem nicht. Woran hängt es denn noch?

Hallo,

Zitat:

---

Zitat von tab

Bzw was macht denn der Button, auf den du nur noch klicken musst? Kann das ein Cronjob nicht?

---

Der Button ist ein Icon auf dem Desktop meines PCs, der ein Batch-File aufruft, der über plink (ähnlich putty) eine ssh-Verbindung öffnet und eine Reihe von Befehlen absetzt, die letztendlich ein tar-File auf dem Server erzeugen, in dem alle zu sichernden Verzeichnisse und Dateien sind. Ein Cronjob kann das nicht aufrufen, weil mein PC nicht immer online ist. Und wie ich die gleichen Befehle auf den Webserver ausführen könnte, weiß ich nicht. Insbesondere müsste man dann auch den Namen des tar-Files dynamisch ändern, wie das Samson1964 weiter oben sehr schön gemacht hat ... allerdings mit PHP.

Was mich nach wie vor wundert ist, dass es für so eine einfache Angelegenheit keine (Server- PHP- ... was auch immer) Bordmittel gibt, die sowas erledigen können, sondern dass es hierzu wieder neue (mehr oder wenige kompatible) Tools braucht und man sich wieder in irgend welche neuen Script-Welten einarbeiten muss. Ich denke, ich werde es beim manuellen Backup belassen.

Danke und Ciao
HaPe

Zitat:

---

Zitat von HaPe

... Es wäre ausreichend, wenn einfach das komplette Contao-Verzeichnis (ca. 1. GByte) gezippt auf den gleichen Server gelegt wird.

... ich brauche eine automatisierte Lösung...

---

Die Lösung dürfte ja damit hier in diesem Thread gefunden sein.

Wen's auch interessiert, ich habe gerade nochmal Reoback eingerichtet. Es ist ein Perl-Script, somit gibt's auch keine PHP-Limitations. Einfach auf den Server legen und mit nem Cron anstoßen. In ner Conf-Datei stellt man ein, welche Ordner man sichern oder ausschließen möchte. Ich kann da gerne Hilfe geben.

Ich habe das Script ein wenig modifiziert, weil mir nicht gefiel, dass PM und AM im Dateinamen enthalten sind - z.B. 20160510-448PM => 20160510-1648. Dann gefiel mir nicht, dass für jeden Tag ein Ordner angelegt wird - "2016-05-10". Außerdem habe ich das Verhalten der incrementellen Sicherungen angepasst (siehe unten). Die Backups laufen so (wenn der Cron täglich läuft):

Code:

---

backupdays = 7

DAY BACKUPTYPE          | DAY BACKUPTYPE
---------------------------------------------------
1  Full                |  8  Full
2    Incr              |  9    Incr
3    Incr              | 10    Incr
4    Incr              | 11    Incr
5    Incr              | 12    Incr
6    Incr              | 13    Incr
7    Incr (Delete 8-14) | 14    Incr (Delete (1-7)

---

Also wenn man Sicherungen für 7 Tage behalten möchte, dann werden erst am 14.Tag die ersten 7 Dateien gelöscht, weil dann erst die nächsten 7 Tage komplett sind.

Was ich geändert habe:

Das Default Verhalten ist so, dass wenn z.B. am Tag 2 eine geänderte oder hinzugefügte Datei erkannt wird ein incr. Backup mit dem Inhalt nur dieser Datei erstellt wird (werden keine Änderungen gefunden, wird auch keine Datei erstellt). Jetzt kommt das Doofe. Wenn sich am 3. Tag eingentlich nichts geändert hat und somit auch keine Datei erstellt werden muss, erstellt es trotzdem eine mit dem gleichen Inhalt wie am 2. Tag, weil es immer das Full als Referenz nimmt. Das hieße, dass ich am 7. Tag 7 Backup-Dateien haben könnte, obwohl es eigentlich nur an Tag 2 eine Änderung gab. Man könnte auch sagen, die inkrementellen Backups sind kumulativ. Dieses Verhalten habe ich geändert.

Und ich dachte immer, Unix hat Batchdateien und Scripts erfunden ;). Warum sollte der Server irgendwas mit Dateien nicht machen können, was du von deinem PC aus auf dem Server machen kannst? Und wenn du die Befehle aus einem Script heraus aufrufst anstatt aus deiner lokalen Batch-Datei übers Netz, dann kann mit einem Cronjob das Script regelmäßig zu den gewünschten Zeiten aufgerufen werden. Da wird dein PC nicht gebraucht. Backup-Scripte gibt es im Internet auch zu Hunderten (stark untertrieben), manche sehr komfortabel, manche eher einfach, ist sicher für jeden Geschmack was zu finden.

Ich habe da nur eine kleine Empfehlung: Legt wenigstens einmal im Jahr ein Vollbackup der Website (oder gleich all eurer digitalen Daten die ihr überhaupt besitzt) auf eine verschlüsselte externe Festplatte und platziert die dann in einem Bankschließfach/bei vertrauenswürdigen Freunden/etc. ... eine solche physische Auslagerung, die man aber notfalls doch schnell erreichen kann (auch ohne das erst von einem Online-Speicher runterladen zu müssen o.ä.) kann Gold wert sein, wenn euch Büro/Haus/Wohnung abfackelt. Ist Kollegen/Kunden so passiert - die externe Sicherung hat ihnen die Firma gerettet.

Lokale Sicherungen sind auch wichtig, aber in Extremfällen nicht mehr hilfreich. Ich stand auch schon bei einem Kunden vor den ganzen lokalen Backup-Servern, während wir gemeinsam mit den Admins überlegt haben, wie wir diesen realen Datenwert am brennenden Vorderhaus vorbeibekommen, falls das Feuer auf das weitere Bürogebäude zugreift ... sehr unerfreuliches Erlebnis, das mir die Augen geöffnet hat.

Und hier noch eine ganz abstruse Idee: mal nachgesehen, ob dein Hoster dir Backups anbietet?

Laut dem Google Orakel soll das sogar Strato hingekommen 😉:

https://www.google.de/url?sa=t&sourc...zugreifen.html

Gesendet von meinem D5803 mit Tapatalk

Also ich verstehe das immer noch nicht, was gibt es denn einfacheres bei einem popeligem Webspace als die Möglichkeiten des Anbieters zu nutzen?

https://www.strato.de/faq/article/10...zugreifen.html

Hallo,

Zitat:

---

Zitat von css-umsetzung

Also ich verstehe das immer noch nicht, was gibt es denn einfacheres bei einem popeligem Webspace als die Möglichkeiten des Anbieters zu nutzen?

---

ja danke, das wurde jetzt schon dreimal genannt.

Im Prinzip ist das schon mal besser als gar nix. In dem letzten Problemfall hätte mir genau diese Methode aber wenig geholfen, deshalb kann ich die Begeisterung nicht so ganz teilen. Es hatte sich ein Problem eingeschlichen (dessen Ursache mir immer noch nicht wirklich klar ist) und ich hätte ein ganz bestimmtes Backup benötigt, das es mal gegeben hat, das aber inzwischen durch das zeitliche Raster der Strato Backup Strategie gefallen ist und nicht mehr vorhanden war. Ich sichere die Datenbank einmal täglich automatisch und eigentlich bräuchte ich halbwegs zeitsynchron die zugehörigen Files.

Ciao
HaPe

Aber wer behält denn ein Backup länger als 4 Wochen?

Strato sicher ja täglich für eine Woche, und hat für 4 Wochen, je Woche 1 Backup vorrätig.

Klar ich sicher auch länger, aber nur der Kunden wegen.
Ich sage mir aber immer, was ich in einer Woche nicht bemerkt habe, kann nicht so wichtig gewesen sein.

Zitat:

---

Zitat von css-umsetzung

Aber wer behält denn ein Backup länger als 4 Wochen?

---

Ich.
Wenn der Webspace volläuft, lade ich alle Dateien herunter und sichere sie lokal. Das betrifft vor allen Dingen die MySQL-Backups und Logfiles. Vom Webspace mache ich auf dem Server nur Backups der wichtigsten Verzeichnisse. Desweiteren synchroniere ich das Serverweb mit meiner lokalen Kopie in unregelmäßigen Abständen. Zwei- bis dreimal im Jahr packe ich das ganze Web und archiviere es auf externen Festplatten oder DVD. Theoretisch könnte ich so z.B. von schachbund.de vollständige Webs ab etwa 2004 für historische Recherchen zur Verfügung stellen. So wie es auch der Bundestag macht.

Als ich an einem neuen Web bastelte und noch kein Backup der Datenbank dafür angelegt hatte, habe ich mal meine Datenbank versehentlich geleert. Ich war der Meinung ich würde die Tesdatenbank leeren, stattdessen löschte ich die Tabellen der aktiven Datenbank. Damit hatte ich praktisch eine Woche Arbeit zunichte gemacht. Glücklicherweise konnte mir Domainfactory aus der Patsche helfen. Sie bewerben zwar nicht extra, das sie auch Backups anlegen, aber so konnte ich doch noch auf ein Datenbank-Backup zurückgreifen und mußte nicht von vorn anfangen.

Zitat:

---

Zitat von Andreas

Wen's auch interessiert, ich habe gerade nochmal Reoback eingerichtet.

---

Ich bin gerade dabei auch mal meine Backupstrategie für das Filesystem zu überdenken. Wenn ich mir Reoback so anschaue, dann ist die Version 1.0 Release 3 ja nicht ganz taufrisch.
Gibt es da etwas neueres was ich übersehen habe?

Ja, die ist ziemlich alt. Ich kann kein Perl, aber das ist ja mehr oder weniger nur das Finden und Einpacken von bestimmten Dateien nach Abgleich, was bei dem letzten Backup bereits gemacht wurde.

Hatte die reoback.pl aber trotzdem mal ein wenig angepasst, z.B. weil mir das Datum nicht gefiel. Hier mal meine Version http://public.andreasburg.de/reoback.zip