3.0.3 & Backup

[frantek]

Hallo,

ich hab ein bisschen herum gelesen und irgend wo gesehen, dass die neue Backupfunktion Datenanken nicht mit sichert. Ist dem etwa wirklich so ? Das wäre sehr schade, da kein Kunde verstehen wird warum das so ist. Ich hab mir das noch nicht näher angeschaut ... wie ist das generell mit einem Backup ? Ohne geht es ja wohl überhaupt nicht. Die bewusste Backupfunktion betrifft wohl nur Kunden, oder ? Wie sieht es mit einem generellen Systembackup aus ? Muss man sich das nach wie vor selbst bauen ?

TIA
Matthias

 

[Till]

Die Frga elässt sich ganz einfach beantworten.: Bei dem Backup handelt es sich um ein webseiten backup. Es wird also eine Webseite gesichert und nicht ein ganzer Kunde, da ein kunde ja auch garkein eigenes Verzeichnis oder FTP Login hat. Wenn Du jetzt die Datenbankliste ansiehst, wirst Du feststellen dass die Datenbanken ja garkeiner Webseite zugeordnet sind, also kann ein backup Script ja auch garnicht wissen, zu welcher Webseite die DB gehört.

Es ist geplant dass wir in einer der nächsten Releases die Datenbanken fest einer Webseite zuordnen und dann könne sie auch mit ins webseiten backup aufgenommen werden.

Für komplette Systembackups gibt es jede Menge Software. Z.B. tar, duplicity, rsync, backuppc etc. Da werden wir das Rad nicht nochmal neu erfinden in dem wir die x100ste System Backup software schreiben. Außerdem sind solche Setups immer sehr spezifisch für den jeweiligen Server und Provider, der eine sichert auf eine externe Festplatte, der nächste auf einen Netzwerk Drive, ein NAS, einen FTP Server, auf einen amazon storage Server etc. Für jede dieser varianten gibt es fertige Software und scripte.

 

[frantek]

Datenbanken Webseiten zuzuroden ist meiner Meinung nach der falsche Ansatz. Ich hab mir das alle noch nicht so genau angeschaut, aber logisch wäre für mich, dass ein Kunde N Domains haben kann und somit N v-Hosts und eben auch N Datenbanken. Für Ein Backup welches der Kunde durchführt ist dann nicht relevant zu welcher Webseite die DB gehört sondern dass sie zum Kunden gehört. Meiner Meinung nach gehört in ein solches Backup:

- Document-Root
- Logs
- Mail, falls IMAP benutzt wird
- Datenbanken

und zwar immer - wie gesagt - pro Kunde .... halt alles was nötig ist, damit der Kunde von Null ohne Verluste wieder starten kann. Interessant wäre dann sicher auch noch das selektiv machen zu können, aber das ist dann schon wieder eher "nice to have".

... das ist aber nur meine, persönlich, unmassgeblich Meinung

 

[mbsouth]

@Till

Meine Meinung dazu - falscher Ansatz!
Als ISPConfig Newbee nehme ich aber gerne Belehrungen entgegen:

Es wird also eine Webseite gesichert und nicht ein ganzer Kunde...

Eine "leere" Webseite zu sichern, welche den Großteils des Contents in einer DB speichert (z.B. CMS) hat wenig Sinn!

... da ein kunde ja auch garkein eigenes Verzeichnis oder FTP Login hat.

/var/www/clients/client[client_id]/...

Wenn Du jetzt die Datenbankliste ansiehst, wirst Du feststellen dass die Datenbanken ja garkeiner Webseite zugeordnet sind, also kann ein backup Script ja auch garnicht wissen, zu welcher Webseite die DB gehört.

Nicht zu welcher Webseite aber zu welchen Kunden die Datenbank gehört:
Database Name Prefix: c[CLIENTID]
Database User Prefix: c[CLIENTID]

Es ist geplant dass wir in einer der nächsten Releases die Datenbanken fest einer Webseite zuordnen und dann könne sie auch mit ins webseiten backup aufgenommen werden.

Das wäre auch schon jetzt (3.0.3) möglich:
System Config/Interface Config/Sites:
Database Name Prefix: [CLIENTNAME]
Database User Prefic: [CLIENTNAME]

In meiner ersten ISPConfig-Teststellung verwende ich als [CLIENTNAME] die Kundennummer. Diese ist sowohl auf den Servern als auch in der restlichen Unternehmensstruktur einzigartig.

mbsouth

 

[Till]

1) Jeder ISP sichert sowieso alle Datenbanken zentral. Solch ein datenbankbackup für den Kunden dient aso sowieso nicht der Ausfallsicherheit sondern damit der Kunde mit der DB z.B. zu einem anderen Anbieter umziehen kann oder er eine Kopie der Seite aufsetzen kann. Dafür stehen dem Kunden aber bereits die Funktionen in phpmyadmin zur verfüging und das Backup müsste er ja auch über phpmyadmin zurückspielen.
2) Auf das Verzeichnis /var/www/clients/client[client_id]/ kann kein Kunde zugreifen.
3) Das sichern der Webseitendateien macht sehr wohl sinn, denn das ist der Teil in dem der Kunde Datien ändert und es steht im Gegensatz zu den Datenbanken eine andere Möglichkeit alle Dateien auf einmal zu sichern.

 

[mbsouth]

Hallo Till, danke für dein Feedback.

1) Jeder ISP sichert sowieso alle Datenbanken zentral. Solch ein datenbankbackup für den Kunden dient aso sowieso nicht der Ausfallsicherheit sondern damit der Kunde mit der DB z.B. zu einem anderen Anbieter umziehen kann oder er eine Kopie der Seite aufsetzen kann. Dafür stehen dem Kunden aber bereits die Funktionen in phpmyadmin zur verfüging und das Backup müsste er ja auch über phpmyadmin zurückspielen.

Natürlich sichert der ISP DBs zentral, schon klar. Das der Kunde seine DB mit phpMyAdmin, mySQLDumper etc. sichern kann, ist auch klar. Die Quintesenz an der Sache ist aber, dass der Kunde gerade keine aktuelle Sicherung hat, wenn diese benötigt wird. Dann wird wiederum der ISP mit dieser Aufgabe betraut. Nur welcher ISP hat Lust, aus einem Dump von 2000 Datenbanken mit 100.000 Tabellen einen Guestbook-Table mit 20 Records herauzusuchen, der aufgrund eines Schrott-Scripts vernichtet wurde? Da wird dann schon eine ordentliche Rechnung gestellt. BackUp und Recovery sind kein nice-to-have sondern ein must-to-have - auch auf Kundenebene!

2) Auf das Verzeichnis /var/www/clients/client[client_id]/ kann kein Kunde zugreifen.

Aber ein BackUp- und Recovery-Script könnte es, per Cron-Job ausgeführt: Webseite, mySQLDumps (DatenDB + User- Zugriffsberechtigungen des Kunden) in ein *.gz verpackt.

3) Das sichern der Webseitendateien macht sehr wohl sinn, denn das ist der Teil in dem der Kunde Datien ändert und es steht im Gegensatz zu den Datenbanken eine andere Möglichkeit alle Dateien auf einmal zu sichern.

Ja, da gebe ich dir Recht - bedingt -, weil keine Kunde Dateien am Server ändern wird. Eher vor Ort (Büro etc.), z.B. in einer XAMP Umgebung. Die sind dann meistens eh´ aktueller als am Server.

Der Punkt auf dem "i" wäre halt eine Datensicherung für DB + Web + Benutzereinstellungen (Punkt auf dem großen "I"), pro User (Client), per Cron-Job ausgeführt (tägl., wochentl., monatlich.).

mbsouth