Hello,
Den Server runter fahren wird eher nicht möglich sein, da das ja nicht bei mir ist, sondern bei einem Anbieter.
An sich ist das nicht Nötig, der Tom geht die dinge anders an als wir „vielleicht irgendwann mal Programmierer“.
Wie kommst Du darauf, dass es nicht notwendig ist, während der Sicherung Veränderungen an den Daten zu verhindern? Je nachdem, wie besucht die Seite ist und wie stark daher Änderungen in der DB stattfinden, wirst Du Inkonsistenzen bekommen, wenn Du den DB-Server nicht daran hinderst, normal weiterzuarbeiten, während Du die Kopien ziehst.
Wenn man das nicht über anständige Wege erreichen kann, muss man eben unanständige Wege gehen:
In der Applikationsschicht ein "disable Login"-Flag einbauen in alle Scripte und bevor man sichern will, setzt man das (das sollte das Sicherungsscript tun). Erst wenn keine offenen Connections mehr besthehen außer der eigenen werden alle Tabellen vom Sicherungsscript geflusht und erst dann fängt man an mit dem Dump der Tabellen. Wenn das Sicherungsscript damit fertig ist, setzt es das Login-Flag wieder auf "enable Login" und alle Scripte kömnnen wieder mit der DB arbeiten.
In den Scripten würde ich das per Umleitung abfangen:
if (!get_enable_login())
{
header('Location: http://wartungsarbeiten.example.org');
}
Und das Flag legt man am besten in einer gemeinsamen Datei ab, die dann über die Funktion ausgelesen wird. Da die meisten Coder sowieso immer ein "include datenbank.php" am Anfang ihres Scriptes einbauen, wäre der passende Ort für die Prüfung also in diesem php-include-Script.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg