Backup-Strategien - (HTML)-Code Ausgabe aller Nodes

Was soll dir das denn bringen? Das ist etwa soviel Wert wie ein Backup auf Papier.

Warum benutzt du stattdessen keine "ordentliche" Backup-Strategie?

Sind die Linux-User von heute etwa nur noch reine User? ;-)

--
Webseiter

Wir können gerne über eine Backupstrategie diskutieren, aber bitte unter der Voraussetzung, dass der Hoster Mist baut und zwar so schlimm, dass man sich nur mehr auf den Kopf greift und alles aus der letzten Zeit verloren ist. In so einer Situation hilft auch die Entscheidung nicht, dass man den Hoster wechselt, denn dann ist es schon zu spät. Ich habe nun schon einige Male Hoster gewechselt, die so um die 1-2 Jahre bestens funktioniert haben. Es gab wirklich keine Probleme, ich war voll zufrieden und dann musste der Server gewechselt werden, weil die Hardware defekt wurde, etc.. Kein Hoster schaffte es die Sicherung so einzuspielen, dass es wieder genauso wie vorher funktioniert hat. In der Regel sind es Rechteprobleme und da wieder "nobody"-Dateien. Mittlerweile habe ich in dieser Richtung einiges dazu gelernt, was so alles falsch laufen kann. Drupal ist ja noch ziemlich pflegeleicht, wenn man _selber_ zurücksichert und hoffentlich nicht übersehen hat, dass man bereits ein kaputtes Drupal gesichert hat.

Die Frage ist, wie prüfe ich, ob ein Backup etwas taugt. Das merkt man in der Regel erst bei einem Restore und bei einigen Restores hatte ich in letzter Zeit meine blauen Wunder erlebt, Stichwort Permissions. Es ist ja noch relativ harmlos die Rechte von "files" wieder auf 777 zu setzen. Etwas komplexer wird es schon, wenn man sich über .../?q=user gar nicht anmelden kann. Ok, war alles lösbar. Bei letzterer Situation half es, "themes" zu löschen und neu auf den Webspace zu kopieren. Das Problem mit den Hoster-Backups ist, dass sie ohne zu fragen Konfigurationen ändern und man von einem Tag auf den anderen kaputte Backups hat, von denen man gar nicht weis, dass sie kaputt sind. Kürzlich erlebte ich die Situation, dass der Hoster den Account auf einen anderen Server gab und ohne zu fragen den Usernamen änderte, konkret eine 1 an den Usernamen daran hängte, da dieser schon existierte, wobei nicht daran gedacht wurde, dass dann die Konfigurationsfiles auch nicht mehr passen, da bei cpanel der DB-Name und der DB-User eine Kombination aus dem Accountnamen bilden. Wie üblich wurde alles abgestritten und man muss selber suchen.

Daher ist meine Überlegung, was kann da noch alles passieren und was wäre im schlimmsten Fall wünschenswert, und das sind meiner Meinung eben nach Textdateien mit den Codes der einzelnen Nodes. Nicht, dass ich viel Lust hätte, die Nodes manuell neu anzulegen, aber am meisten Arbeit wäre eben den Code für die Nodes neu zu erstellen und das zu speichern wäre zusätzlich zur Standardsicherung schon interessant.

Eventuell könnte man das auch mit einem mysql-Befehl erreichen und die Tabelle node_revisions exportieren. Aber bevor ich mir das im Detail ansehe, wollte ich fragen, ob es dafür bereits etwas ähnliches gibt.

_____________
drupal-6.6-DE

nimm boxbackup und sichere deine kompletten daten auf deinem rechner in deinem schlafzimmer. ist doch easy, oder?

Hallo,

ich benutze für so etwas gerne HTTrack, http://www.httrack.com/

Nicht unbedingt als Backup, aber z.B. für statische Offline-Versionen, oder um die Site-Struktur zu kontrollieren.

Gruß,
Boris

HTTrack findet sich im Opensuse-Repo, Box Backup nicht, daher habe ich HTTrack probiert, genau webhttrack. mit httrack sollte man mehrere Backups mit einem Script automatisieren können.

Mein größtes Problem ist noch, wie erkennt die Sicherungsroutine automatisch, dass die Webseite kaputt ist. Bei hunderten von Seiten und mehreren Homepages, kann man nicht immer manuell kontrollieren.

Gibt es so etwas wie ein Änderungslog? Dann könnte man die Nodes überfliegen, die geändert wurden.

_____________
drupal-6.6-DE

Nun, ich kann natürlich nicht für andere Hoster sprechen und bin froh, dass sowas bei mir noch nicht vorgekommen ist. Bei mir wird jede Nacht für jedes Web die DB und der Web-Ordner komplett gepackt und per FTP gesichert.

Nun könnte ich darüber nachdenken zusätzlich meine Root-Server noch untereinander Backups speichern zu lassen, oder - wenn ich viel Geld und Zeit über habe - einen Server dediziert nur als Backup-Server laufen lassen und z.B. mit rsync arbeiten, oder Amazon S3, oder oder oder...

Jedenfalls wird das Backup bei mir im Kundenordner abgelegt. Per FTP kann sich also im Grunde jeder Kunde manuell oder automatisch sein Backup-File der letzten Nacht ziehen oder wer-weiß-was damit treiben.

Das mit dem Restore ist der Standard-Knackpunkt, der vor allem auch für "normale" Backups, egal ob auf zweite Platte, externe Platte, NAS, Bandlaufwerk, ... Keiner macht sich die Mühe mal zu schauen, ob er mit seinem Backup auch das System wirklich komplett zurückgespielt bekommt. Obwohl.. das Time Machine Backup meine iMac wohl primstens funzt, wie die Komplettübernahme auf mein MacBook die Tage bewiesen hat...

Kurzum:
Die Angst kann dir erstmal keiner nehmen und Geschäftsbeziehugnen basieren immer auf Vertrauen. Im Zweifelsfall kannst du dir mit deinem statischen HTML auch nur den Popo abwischen, wenn dein System ausfällt und das Backup korrupt ist. Sinnvoller wäre die Zeit darin zu investieren ab und an das Backup zu kontrollieren.

Keine Ahnugn was für komische Hoster du dir gesucht hast, dass die dauernd unangemeldet Zugangsdaten, Server, etc. ändern. Es gibt leider viele Frickler und Schweinepirester in dem Bereich. Würde ich denn mit meiner Annahme richtig liegen, dass du dir stets sehr günstige Hoster gesucht hast?

--
Webseiter

Das bringt dir wenig bis gar nichts. Wenn deine Seite auch nur ein bisschen größer ist, wirst du aus so einem HTML Dump nie wieder 'ne lauffähige Drupal Installation zaubern können. Wenn du was backupen willst, musst du eigentlich nur einen Dump deiner Datenbank und das "/sites" Verzeichnis mittels rsync o.ä. in Sicherheit bringen.

Man könnte sich beispielsweise auch daheim ne Sychronisation stricken, die einem die Drupal-Installation lokal lauffähig macht. Dazu müssen ja nur ein paar Sachen in der Konfiguration angepasst werden. Dann weiß man auch auf einen Klick, ob es funktioniert.

--
Webseiter

Du hast vollkommen recht, Fernziel ist eine lokale Drupal-Installation (mit allen Möglichkeiten als root), die mit dem Web synchronisiert wird. Da es um viele kleine Drupal-CMS geht, muss ich zuerst den Apache richtig konfigurieren und da hakt es zur Zeit bei den vhosts.

Einen gravierenden Nachteil von httrack habe ich schon entdeckt. Während die komprimierte Komplettsicherung der Domain ca. 50MB hat, bin ich nun nach 90 Minuten schon bei 500MB lokal. Ich muss eine Lösung finden, dass die Taxonomy-Links nicht mitgesichert werden. Außerdem frisst das meine Bandweite auf.

Eventuell macht es Sinn die Seite des Moduls IndexPage mit httrack inklusive "1 Link tief" zu sichern.

_____________
drupal-6.6-DE

Ich versuche "/indexpage/story/all" mit webhttrack zu speichern. Die Option "Set Options/Limits/Max Depth" reagiert nicht. Es wird auch bei der Angabe von 3 nur die "/indexpage/story/all" gepeichert und keine darunter liegenden Seiten. Alle anderen Werte sind default.
_____________
drupal-6.6-DE

rpm fuer suse kannst du dir schnell selber "basteln"

http://www.boxbackup.org/trac/wiki/CompileLinuxRPM