2012 - Im Titel steht schon so Einiges drinnen, das uns seit Längerem beschäftigt.

Was war bisher nicht so effektiv ? :

1. Sichern der Datenbanken einzeln mit phpmyadmin ist mühsam/zeitaufwendig
2. Kopieren der Filesysteme einschließlich der mysql Datenbanken mühsam/zeitaufwendig
3. Typo3 Backup in t3d Dateien - bricht bei großen Webs meist mit timeout ab.
4. keine (automatischen) Informationen über die damaligen Typo3 Source Versionen

Bei jeder der Methoden gab es Hinkefüße oder keinen Automatismus mit protokolliertem Sichern und Rücksichern.

Wir sichern nur die essentiell notwendigen Typo3- (Netto-) Daten, nicht die verschiedenen Typo3 Core Grundsysteme, (die ja für alle virtuellen Vhost-Webs auf diesem Server nur einmal vorhanden sind.) Dazu sichern wir auch eventuell installierte globale Extensions und weitere !! globale Verzeichnissse. Bei uns sind das die Werbebanner Bilder, die (bei uns) für insgesamt 6 Domains allgemein verfügbar sein sollen.

Alle zu sichernden Host-Dateien liegen auf unseren eigenen RDE Servern auf einem eigenen (physikalischen) Laufwerk für alle V-Hosts (bei uns gemappt auf "/vol2/www/").

1. Die (selektierten Tabellen) der einzelnene Typo3 Datenbanken als mysql dump
2. das Verzeichnis /fileadmin/
3. das Verzeichnis /typo3conf/ mit den local Extensions
4. das Verzeichnis /uploads/
5. das Verzeichnis /typo3/ext/ mit den globalen Extensions
6. unser Verzeichnis /typo3/werbe-banner-folder/
   
   
7. weiterhin sichern wir einmalig für diesen Linux-Server das gesamte Verzeichnis /etc/*

-

Frühe Korrektur vom 16.7.09 - Die sieben (oder mehr) Typo3 "cache_xxxxx" Tabellen (bei 4.2.xx) werden beim Datenbank-Dump ausgeschlossen (excluded) und die Verzeichnisse unterhalb von /typo3temp/ werden nicht gesichert und auch nicht mehr automatisch (beim Sichern) geleert. Das kommt später noch dran.

Nachtrag Jan. 2010: Sämtliche leicht zu reproduzierenden Index-Datenbanken oder Tabellen werden nicht mit gesichert. Dies betrifft auch die offline erstellten mnogosearch Indextabellen. Selbst die leere Datenbank (also ohne Tabellen) muß nicht gesichert werden, die muß um Falle eine Falles nur erneut angelegt werden und das geht mit einer Commandline-Zeile.

Auf unseren Servern werden die allgemein verfügbaren Extensions soweit möglich, immer "global" bevorratet (sofern sie korrekt programmiert sind und auch funktionieren). Die müssen nämlich nicht immer (und immer wieder) doppelt und dreifach "local" vorhanden sein. Die Konfiguration steht sowieso im jewels zu sichernden Web in der Konfiguration. Und so zählen diese "global" Extensions mit zu unserer Sicherung.

Nachtrag Jan. 2010: Neben den globalen Extensions im "/typo3/ext/" Verzeichnis verlagern wir weitere globale Elemente dorthin, wie zum Beispiel die gemeinsamen Werbebanner, die für viele (also für mehr als 2) Domains vorgehalten werden müssen.

ehemals !!! :
1.) die vorbereitende Bereinigung der Temp-Dateien und Cache-Umgebungen
2.) die eigentliche Sicherung des (Netto-) Inhaltes jedes einzelnen Webs
und das hier kommt noch !! :
3.) der Transfer auf die lokalen Backupserver hier bei uns im Büro/Serverraum

Die aktuelle Sicherung teilt sich wiederum in das Packen des Filesystems und in den Dump der jeweiligen Datenbank auf.

Das mit dem Leeren unter 1.) und dann Sichern unter 2.) haben wir aus Performance-Gründen wieder getrennt. Wenn nach jeder nächtlichen Sicherung die Cachetabellen und die Tempdateien neu aufgebaut werden müssten, ist das bei unseren aufwendig bebilderten RDE Museumsseiten extrem schleppend, also inakzeptabel.

Es gibt pro Typo3 Web ein Typo3 root Verzeichnis, dort drinnen sind für uns 3 Verzeichnisse zu sichern:

2.a) fileadmin
2.b) typo3conf
2.c) uploads
und
2.d) "Globale Extensions" sichern aus: /typo3/ext/ (aber nur einmalig mit der ersten zu sichernden Domain) - und alle 4 Verzeichnisse sofort in einem Durchgang einzeln mit tar und gzip (xxxyyy.tar.gz) packen.

Der mysql daemon braucht für unsere bisherigen Zwecke nicht angehalten zu werden (wir brauchen NOCH keine referentielle Integrität der Tabellen), er kann also (muß sogar) weiter laufen.

Grundsätzlich sollen alle Tabellen der jeweiligen Datenbank (auch die der Erweiterungen) gesichert werden. Die Typo3 CACHE-Tabellen (eigentlich alle aus dem Datenstamm restaurierbaren Tabellen) werden in der mysql Commandline excluded !!! und NICHT mit gesichert.

Der Mysql-Dump aller Tabellen wird initiert (immer Tabellen-Strukturen und Tabellen-Inhalte !! gemeinsam) und im temporären Verzeichnis (zusammen mit den 3 Dateisicherungen) abgespeichert und als gzip gepackt, sodaß zu jeder Sicherung am Ende pro Domain 5 gepackte Dateien mit dem Logfile gehören (+ einmalig die globalen Extensions für diese Typo3 Version).

Geteilte Shell-Script Abwicklung per Cronjob
(das wäre optimal wegen der Pflegbarkeit pro root-Server)

1. Parameter-Datei 1 (= domains.dat) enthält die Domain-Variablen-Definitionen der zu sichernden jeweiligen mysql Datenbanken, mysql User und mysql PW !!! (aufpassen) sowie die Rootverzeichnisse der zu sichernden Webs.
   
   
2. Parameter-Datei 2 (= server.dat) enthält die Server-Variablen des zu pflegenden Servers und eine oder zwei e-mail Adresse(n).
   
   
3. Das eigentliche Backup-Script heißt bei uns "copy-home" Script und enthält das eigentliche Sicherungs-Jobsystem : Kopieren bzw. Auslesen, Packen und Wegsichern, Prüfen, Protokollieren (auf dem Server) sowie das Mailen des Protokolls.

-

1. $domain-namen (zur eindeutigen Benennung des Sicherungsverzeichnisses, nicht der Dateien !!)
2. $mysql-datenbank (der mysql Name der jeweiligen Datenbank muss nicht mit der Domain übereinstimmen!!))
   Diese beiden sind wichtig, können nämlich pro Domain-Datenbank unterschiedlich sein
3. $mysql-user
4. $mysql-passwd
5. $web-root-directory    (jedes Web hat nur ein eindeutiges root-verzeichnis)
   --
   ab hier automatisch abfragen und ins Log eintragen
   --
6. $typo3-revision           (Abfrage der Typo3 Version über den symlink von /typo3/ )
7. $mysql-revision          (Abfrage der mysql Version - sollte auch mit ins Logfile)

.

1. $temp-directory          (dort werden die Backup-Zwischendateien temporär abgelegt)
2. $ziel-directory             (z.B. in /var/log/web-sicherungen/  es kommt dort noch das Tagesverzeichnis hinzu)
3. $datum-uhrzeit           (wird aktuell aus dem System geholt)
4. $email-adresse           (Mailadresse des Admins, der die Datensicherung evtl korrigieren muss)

-

Die Shell Scripts (inzwischen nur noch 1 Script) sowie die beiden ".dat" (include-) files müssen !!! User=root und Gruppe=root haben und müssen ausführbar sein. Sie dürfen KEINE Leserechte für Gruppen oder Andere oder Sonstjemanden haben !!!! (das mysql Passwort ist dort im Klartext drinnen) und sie sollten in einem Verzeichnis in "etc/irgendwo" untergebracht werden, denn /etc/ ist sowieso nur dem user root vorbehalten !!!!

Im generellen Ziel-Verzeichnis für die Sicherungen gibt es ein (einziges) Tages- Unterverzeichnis. Auch hier hat nur der user "root" Rechte, niemand absolut sonst !!!!!

Die File-Namen (einer Domain-Sicherung) enthalten am Anfang !! (in dieser Reihenfolge) das Erstellungsdatum, dazu die Uhrzeit (ist handlicher) = year-month-day-hour-minute, sodaß durchaus mehrere Sicherungen am selben Tag angestoßen werden können. (Jede Sicherung dauert mindestens 1 Minute, eher länger, darum gibts keine doppeten Namen) Danach wird der mysql Datenbankname eingefügt (bei uns also nicht der Domain-Name !!).

Weder das Rootverzeichnis noch der Domainname (die interessieren nur den Vhost-Eintrag des Apache) ist für eine Rücksicherung (z.B. auf den Ersatz-Server) wichtig !!

Das Zielverzeichnis für die gesicherten Daten muss/darf auch nur absolut von "root" einsehbar sein.

Am Anfang einer Sicherungsoperation wird ein temporärer "avoid multiuser" check-file "job-in-use-check" angelegt und ganz am Ende nach Erstellen des Protokolls und Versenden der OK-Mail wieder gelöscht. Ist der Tempfile bereits vorhanden, wird "KEINE" (zweite und somit gleichzeitige) Sicherung angestoßen, sondern nur eine Warn-Mail versandt. Es können also nie zwei Backup-Jobs gleichzeitig laufen.

Bitte schauen Sie mal in das jeweils aktuelle Script rein.

Das gibts über eine Mail über unser Formular hier.
www.rde.net/rde-net-kommentar.html
.

Zu sichern wäre die Domain www.fernsehmuseum.info. Es gibt aber auch css.fernsehmuseum.info und html.fernsehmuseum.info.

Alle drei "wohnen" in verschiedenen Root-Verzeichnissen.

Alle drei haben verschiedene mysql Datenbanknamen. Darum haben wir (als Beispiel) folgende Variablen in Script 1 :

$domain-namen = www.fernsehmuseum.info
$mysql-datenbank = fernsehmuseum_info
$mysql-user = U1-usermuwi
$mysql-passwd = pw1- passmuwi
$web-root-directory   = /vol2/www/www.fernsehmuseum.info/
$typo3-revision = 4.2.6

und folgende Variablen in Script 2:

$temp-directory         = /home/temp/
$ziel-directory            = /bak-vol/sicherungen/
$datum-uhrzeit          = 2009-07-11-02-30
$email-adresse          = autobackup@irgendwas.tld

Nach Abschluss der Sicherung:
folgende 5 Files müssten pro Domain (automatisch) erstellt worden sein

im Verzeichnis : /bak-vol/sicherungen/2009-07-11/

2009-07-11-02-30-fernsehmuseum_info-fileadmin
2009-07-11-02-30-fernsehmuseum_info-typo3conf
2009-07-11-02-30-fernsehmuseum_info-uploads
2009-07-11-02-30-fernsehmuseum_info-mysql
2009-07-11-02-30-fernsehmuseum_info-backup-log
-
und eine Mail müsste auch bereits unterwegs sein.

und hätte es eine zweite (händische) Sicherung gegeben

dann nochmal

2009-07-11-09-50-fernsehmuseum_info-fileadmin
2009-07-11-09-50-fernsehmuseum_infotypo3conf
2009-07-11-09-50-fernsehmuseum_infouploads
2009-07-11-09-50-fernsehmuseum_info-mysql
2009-07-11-09-50-fernsehmuseum_infobackup-log

und wieder eine Mail

und einmalig pro Sicherung

2009-07-11-02-30-fernsehmuseum_info-global-ext

Beim Konzept der Rücksicherung gehen wir davon aus, der alte Server sei vollständig abgestürzt und nichts davon sei mehr einsehbar - also es sei wirklich alles absolut weg.

Darum ist uns das Logfile mit allen Informationen von damals (es kann ja durchaus 6 Monate her sein) sowie der Name der mysql Datenbank so wichtig.

Alle zur Restauration relevanten Informationen müssen also vorher schon !!! im (gesicherten alten) Logfile stehen.

Auf dem neuen Zielserver legen wir im globalen Verzeichnis der Webs ein neues Root-Verzeichnis mit dem Namen der Domain an und installieren (einen der Version im Logfile entsprechenden) Typo3 Dummy. Dann ändern wir alles auf (bei Suse) Owner und Gruppe: wwwrun und www.

Auch der Vhost Eintrag in der config des Apache muss natürlich eingetragen werden und ein (ersatzweiser) DNS Eintrag (lokal oder im eigenen DNS Server) ist wichtig.

Sodann erzeugen wir auf diesem Zielserver eine neue leere mysql Datenbank mit dem gleichen Namen wie im Logfile. Dazu ergänzen wir den Typo3 User und dessen Passwort und die Rechte.

Dann importieren wir den mysql Dump in diese Datenbank und rufen über die im DNS eingetragene Hilfsdomain das Backend auf.

So weit die Theorie, das haben wir dann aber noch weiter verfeinert.