Eine Frage zu Backups

[Deleted member 14254]

Hallo @ll,

ich hatte zwar bereits einen ähnlichen Thread gelesen, aber der Hergang war dort etwas anders.

Folgende Frage habe ich:

Ich habe einen Hetzner dedizierten Server auf de ein (SW)RAID-1 läuft.
Ich habe mich bereits mit der Art und Weise der Art und Weise, wie das Backup-Archiv erstellt wird (und auf den Hetzner Backup-Server geschoben) vertraut gemacht.

Nach den Angaben dieser Seiten hier:

http://wiki.hetzner.de/index.php/Backup#N.C3.BCtzliche_Software
http://wiki.hetzner.de/index.php/Tartarus_Backup-Konfiguration

...ist mir der Hergang eigentlich soweit klar. Nur nun las ich in einigen verschiedenen Threads hier im Forum, das man DB einzeln dumpen muss und sichern.

Die Sache ist die: Entweder ich täusche mich jetzt in irgendetwas, oder das Backup würde, mache ich es nach HowTo der Seiten, mir keine funktionierende DB sichern...
Doch wenn ich ab "/" alles sichere, dann müsste das Backup ab "/" bis zum letzten Unterordner irgendwo in "/.../.../.../...Datei" doch meiner Meinung und Erkenntnis nach alles beinhalten. Somit auch die Ordner, in denen DB installiert sind...

Vielleicht steh ich ja gerade auch nur ein wenig auf "dem Schlauch" wie man so schön sagt.

Zuhause mache ich auch Images, aber nicht mit Software wie Tartarus, sondern mit Acronis, das gar Partitionen und RAIDs) sichert. Hier ist es nicht erforderlich, SQL-Dumps anzulegen. Das Image ist ein Original-Abbild der kompletten Platte.

Wenn man aber davon ausgeht, das im Fall des Servers per Tartarus von "/" wie ich schon erwähnte, alles (Inhalt der Platten) gesichert wird... dann müsste man doch keine SQL-DB dumpen und Konsorte extra sichern müssen...

Bin für jeden Wink mit dem Zaunpfahl dankbar (auch ohne Zaunpfahl)

 

[danton]

Du kannst MySQL nur zuverlässig auf Dateiebene sichern, wenn du die Datenbank vor der Sicherung runter fährst. Sonst kann es nämlich passieren, daß MySQL gerade in die Datenbank schreibt, während diese gesichert wird und dann hat deine Datenbank einen inkonsistenten Zustand. Das gilt übrigens auch für andere Datenbank-Server wie Postgres oder MSSQL.

 

[Deleted member 14254]

Hallo danton,

danke Dir für Deine Hilfe
Die Datenbanken, bzw. Datenbankserver MySQL würde ich vorher selbstverständlich runterfahren, die Dienste beenden. Genauso wie den Mailsvr und Apache. Solche Updates würde ich auch nur Nachts machen zu einer dem Kunden bekannten Zeit, damit man sich danach richten kann. Im Moment ist es noch "unabhängig" da noch keine Seite online ist, die Datenbankzugriffe erfordern (CMS).

OT
Acronis, wovon ich gesprochen hatte, "friert" Dienste während dem Lesezugriff kurz ein. Also wenn man das während Systemlauf macht.

Allerdings mache ich Acronis-Images bei mir ausschliesslich bei heruntergefahrenem System per Rescue-CD. Dann ist die Gefahr von Inkonsistenzen praktisch gänzlich ausgeschlossen...
Bei Linux kann ich ohnehin nur die CD nutzen, da ich die Windoof-Version des Programms habe. Der Rescue ist das egal, was sie sichert auf den Sektoren, sie wird ja nicht "installiert".
/OT

Ich werd mich da nochmals einlesen.. Zur Sicherheit mache ich vor dem Sichern (und Beenden von den wichtigen Diensten wie MySQL usw.) dennoch einen Dump. Sollte dann auf Dateiebene was danebengehen und die DB hinterher nicht mehr kaufen, kann ich den Dump einspielen.

Nochmals vielen Dank, danton

 

[danton]

Auf einem Webserver, der öffentliche Webseiten hostet, ist es selten eine gute Idee, die Dienste regelmäßig runter zu fahren, um eine Sicherung durchzuführen. Da sollen die Seiten ja normalerweise 24/7 erreichbar sein.
Und deshalb erstellt man einen Datenbank-Dump und sichert diesen statt der MySQL-Datendateien...

 

[Deleted member 14254]

Hallo danton,

...stimmt! Das leuchtet ein. Ist vielleicht jetzt eine dumme Frage:

Die Dumps - von jeder Datenbank einzeln oder ein Dump mit "allem"?

Bei der Installation von webapps wie phpmyadmin werden zur Konfiguration .sql - Dateien eingespielt um die Datenbank "phpmyadmin und den user pma zu erstellen, beispielsweise. Somit könnte ich mir vorstelen, das man alles in einen Dump packen könnte, aber auch einzeln... Ja, die Frage ist blöd, ich seh es schon, geht mir nur um die Gewissheit.

 

[danton]

So lange es nur für den Desaster-Fall ist, ist es egal. Ich sichere jede Tabelle einzeln, so daß ich diese auch einfach einzeln zurück sichern kann.

 

[Deleted member 14254]

Moin danton

Danke Dir für Deine schnelle Antwort! Ich denke ich werd das erste Vollbackup als Disaster-Recovery auf Dateiebene mit deaktivierten Daemons sichern.
Dennoch zusätzlich die Datenbanken als Dump (.sql) werde ich (sicherheitshalber) ebenso anlegen. Später dann halt nur noch per Dump, da dann wie Du schon angemerkt hattest, es nicht / schlecht machbar wird, wegen den Backups die Dienste zu beenden.

Danke Dir für die Tips! Dann kann ich von vornherein schonmal besser mein "Konzept" entwickeln, wie ich was angehen werde...

 

[d4f]

Je nach Datenbankgroesse und -anzahl ist das Dumpen auf logischer Ebene sehr ressourcen- und zeitintensiv.
Du kannst aber zB Montag morgens ein Fulldump ziehen und an allen anderen Tagen nur inkrementelle Backups (binary log) verwenden.
Es dauert dann zwar entsprechend laenger um ein Samstag-Crash zu reparieren aber dafuer wird der Regelbetrieb nicht weiter beeinflusst.

 

[Deleted member 14254]

Hallo d4f,

ich bedanke mich auch für Deine Anregungen und Tips. Vor allem mit der Recourcenintensivität hätte ich so nicht erahnt. Das ist sehr wertvoll für mich, nun zu wissen!

Die Voll-Dumps lege ich dann in eine Zeit, in der auf dem Server "kaum" was los ist...

Danke Dir

 

[danton]

Das Sichern der Datenbank hängt von mehreren Faktoren ab. Wenn sie nicht allzu groß sind, stellt es evtl. auch kein Problem dar, immer ein Vollbackup zu fahren statt nur das Binary Log zu sichern.
Ich komme damit derzeit problemlos klar und erstelle täglich einen Volldump, während das Dateisystem nur incrementell gesichert wird.

 

[Joe User]

Bei grossen Datenbanken zieht man vom Secondary das Backup und gut ists.

 

[d4f]

Nicht alle physikalisch grossen Datenbanken sind den finanziellen und technischen Aufwand eines Slaves wert.

 

[Joe User]

Einen Slave auf der gleichen Maschine zu betreiben ist technisch, administrativ und finanziell machbar. Soviel muss einem eine grosse DB wert sein...

 

[d4f]

Damit ist man dann bei knapp 3facher Schreib-Belastung (Master, Binlog und Slave) und entsprechendem RAM- und Festplattenverbrauch.

 

[Joe User]

HDD-Platz ist heutzutage kein Argument mehr und RAM braucht ein DB-Slave auch kaum. Die zusätzlichen Schreiboperatonen kann man einkalkulieren, notfalls mit einer eigenen kleinen HDD ohne RAID oder einem USB-Stick. Wenn diese Lösungen nicht mehr reichen, benötigt man ohnehin ein grösseres Portemonaie und kann es in "Enterprise" umsetzen.

Für 0815 (sprich die absolute Mehrheit der hier Mitlesenden) reicht allerdings ein einfacher nächtlicher Dump völlig aus.


BTW: Es hat hier noch keiner FS-Snapshots erwähnt

 

[Deleted member 14254]

Wenn der Server hier nebenan stehen würde, würd ich mir garkeine Sorgen machen... Dann würd ich Acronis anwenden und ein 1:1 vom gesamten System jeden Momant Edit: Monat machen. Der Rest jeden Tag inkrementell...

Aber leider gibts die Möglichkeit nicht (auch wenn sie mich -ehrlich gesprochen- am meisten beruhigen würde)...

Ich könnte mir vorstellen, das Joe soetwas in diese Richtung hingehend mit "FS-Snapshots" im Sinn hatte, stimmts?

Also vom RAM und Plattenplatz sollten bei meinem Server die aufwendigeren Methoden zum Sichern nicht groß ins Gewicht fallen. Das hatte ich bei der Serverwahl berücksichtigt. Da war ja auch der Punkt, das ich anfangs im von mir letztendlich eingesetzten Server-OS noch nicht 100%ig schlüssig war und an die Dauer-kompiliererei bei gentoo dachte. Daher habe ich für ausreichend Performance gesorgt.

Joe, was meinst Du denn da mit "Slave" und "sekundär"... Hört sich irgendwie nach Spiegelungen an, und das Images davon gezogen werden, um nicht das "primary" zu belasten... Sorry, wenn ich da falsch liegen sollte, es sind nur paar Gedanken, die ich mir beim Lesen Eurer Hilfestellungen an mich so mache...

Danke für alle Anregungen!!!

 

[Joe User]

Ich könnte mir vorstellen, das Joe soetwas in diese Richtung hingehend mit "FS-Snapshots" im Sinn hatte, stimmts?

Nein, ich meinte Snapshots nicht Images. UFS, ZFS und NTFS zum Beispiel bieten Snapshots direkt im FS, während LVM (Linux) es als Schicht unterm FS bietet.

Sinnvoller ist allerdings bei MySQL und anderen Datenbanken einen Replikation-Slave aufzusetzen und von dort Backups per Dump zu ziehen, siehe http://www.rootforum.org/forum/viewtopic.php?f=103&t=39167#p302387 beziehungsweise http://blog.koehntopp.de/archives/1177-MySQL-fuer-Dummies-7.html

 

[Deleted member 14254]

Danke für die Erläuterungen, Joe

Ich habe mir mal Deine Links angesehen und mich ein wenig damit vertraut gemacht. Vermutlich werde ich die Dumps aber erstmal auf die "herkömmliche" Weise erzeugen. Allerdings fand ich die Sache mit den "bin-logs" hochinteressant. Die "Master-Server"/"Slave-Server" - Variante ist bei meinem noch recht klein startenden Seiten- und Forenangebot derzeit vielleicht noch leicht übertrieben, Joe.

OT
Hatte vor kurzer Zeit mit TerraX in einem meiner Mail-Server-Threads mal über Zustellungs-Wege der Mails gesprochen, wenn ich das so ausdrücken kann: Er schlug mir auch eine sehr erweiterte Variante der Mailsortierung vor, wir leuchteten dort die sog. "Groupwares" an und gingen bis zum Erwähnen von Ticketsystemen.
/OT

In etwa kann man die jetzige Thematik mit der DB-Sicherung, und die sich mit den Mailzustellungen befassende "Groupware/Ticketsysteme" "auf absolutem Profi-Level" etwas übertragen... Ich meine jetzt von der triftigen Erachtung her, im "richtigen Moment" die vorherrschende Notwendigkeit zu erkennen und umzusetzen, bevor man sich selbst im Wege stehen kann...

Trotzdem, solche Links bieten immer gute Anhaltspunkte, eröffnen neue Sichtweisen und lassen Möglichkeiten für die (hoffentlich erfolgreiche) Zukunft erscheinen.