10. Juli 2009 - 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 damalige Typo3 Version

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 verschiednenen Typo3 Grundsysteme, (die ja für alle virtuellen Vhost-Webs auf diesem Server gemeinsam sind.) Dazu sichern wir auch eventuell installierte globale Extensions und weitere !! globale Verzeichnissse. Bei uns sind das die Werbebanner Bilder, die für insgesamt 6 Domains allgemein verfügbar sein sollen.
Alle zu sichernden Host-Dateien liegen auf unseren 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 spezielles Verzeichnis /typo3/werbe-banner-folder/
   
   
7. weiterhin sichern wir einmalig für diesen Server das Verzeichnis /etc/*

-

Frühe Korrektur vom 16.7.09 - Die sieben 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 geleert.

Wenn die Typo3 "indexed-search Engine" installiert ist (ist eine System- Extension), dann brauchen wir diese 7 oder 8 Tabellen auch nicht zu sichern. Die Inhalte sind (bzw. müssen) mit dem Crawler sowieso aktualisiert werden oder sogar völlig neu aufgebaut werden.

Nachtrag Jan. 2010: Sämtliche leicht zu reproduzierenden Datenbanken oder Tabellen werden ab jetzt nicht 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.

Auf unseren Servern werden die allgemeine verfügbaren Extensions 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 zu sichernden Web. 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 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 packen.

Der mysql daemon braucht für unsere Zwecke zur Zeit noch nicht angehalten zu werden (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 sieben Typo3 CACHE Tabellen (eigentlich alle aus dem Datenstamm restaurierbaren Tabellen) werden in der mysql Commandline excluded !!! und NICHT mit gesichert. (Siehe ganz unten §60)

Mysql-Dump aller Tabellen initieren (immer Tabellen-Strukturen und Tabellen-Inhalte !! gemeinsam) und im temporären Verzeichnis (zusammen mit den 3 Dateisicherungen) abspeichern und als gzip packen, 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. 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. Datei 2 (server.dat) enthält die Server-Variablen des zu pflegenden Servers samt e-mail Adresse
   
   
3. das Backup-Script und auch das copy-home Script  enthält das eigentliche Sicherungs-Jobsystem : Kopieren bzw. Auslesen, Packen und Wegsichern, Prüfen, Protokollieren und Mailen

-

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 ist wichtig, können nämlich pro Domain-Datenbank unterscheidlich 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 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 demSytem geholt)
4. $email-adresse           (mailadresse des Admins, der die Datsi evtl korrigieren muss)

-

Die Shell Scripts 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 !!!! (das mysql Passwort ist dort im Klartext drinnen) haben und sie sollten in einem Verzeichnis in "etc/irgendwo" untergebracht werden, denn /etc/ ist sowieso 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 Filenamen (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. Danach wird der mysql Datenbankname eingefügt (bei uns nicht der Domain-Name !!).

Weder das Rootverzeichnis noch der Domainname (die interessieren nur den Vhost-Eintrag des Apache) ist für eine Rücksicherung 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 und nur eine Warn-Mail versandt.

Bitte schauen Sie mal in das jeweils aktuelle Script rein.

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. 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 relevanten Informationen müssen jetzt im (gesicherten alten) Logfile stehen.

Auf dem neuen Zielserver legen wir im 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.