Backup im laufenden Betrieb...

[kajo0011]

Auf die Gefahr hin, dass mich jemand steinigt, aber:

1. Wie macht man ein Backup im laufenden Betrieb so dass man im Notfall dies verwenden kann um es wieder zurückzuspielen.
Die Beschreibung unter http://server.1und1.com/root_server/backup/3.html kann sich ja nicht auf ein laufendes System beziehen sondern aus der Recovery Console.

2. Wie stelle ich den Server nach einem Schaden wieder her? Bzw. detailierter: wie geht das ganze mit Grub? Auf dem 1und1-Server Suse 81. ist ja Grub drauf... und in http://server.1und1.com/root_server/backup/4.html ist nur lilo erklärt...

3. Ist reoback zuverlässig (ich hab ja nix gegen Schüler; aber soll ich mein Server einem Schüler anvertrauen?)

Danke für Antworten...

[chris76]

Moin,

1. Wieso bist du der Meinung das sich der Link auf ein Backup im Rescue bezieht?

3. IMHO ist reoback zu verlässig. Ich kann mich nich beschweren.

Ciao Christian

[kajo0011]

1. Wieso bist du der Meinung das sich der Link auf ein Backup im Rescuebeziet?

Weil man auf jeden Fall MySQL so nicht im laufenden Betrieb sichern kann (da sich die Dateien ja während der Sicherung ändern können; dies Führt dann zu Problemen bei tar).
Vermutlich gibt es auch Probleme mit Postfix-Files...
Was passiert wenn ein Kunde gerade veränderungen seiner Domain vornimmt... da können auch Inkonsistenzen auftreten (/etc/...)

[chris76]

Also die Datenbanken würde ich grundsätzlich mit einem Dump Sichern!


Ciao Christian

[kajo0011]

Soll man die Datenbank trotzdem noch per tar sichern (also /var/lib/mysql) !?
Oder einfach nur den Dump (mysqldump --all-databases >mysql.sql) und den dann wieder einspielen ?

[captaincrunch]

Das Problem beim Sichern von MySQL per tar wirst du dann merken, wenn du eine andere MySQL-Version mit dem alten Backup nutzen willst, da das in vielen Fällen fehlschlägt. Daher sollte der Weg eher mysqldump heißen.

[kajo0011]

Wieso sicher dann hier jeder "/var/lib/mysql " und "/tmp/mysql.sock" !? (zumindest wenn man die diversen Beispiele von Konfigurationsdateien von reoback nimmt...)

[majortermi]

Wieso sicher dann hier jeder "/var/lib/mysql " und "/tmp/mysql.sock" !?

Datenbanken auf denen kaum Aktivität herrscht, können damit relativ gut gesichert werden. Das sichern von /tmp/mysql.sock ist in der Tat unnötig, weil der Socket beim Starten von MySQL automatisch angelegt wird. Die Datenbanken lassen sich zwar auch direkt sichern, in diesem Fall müsste man allerdings vor dem Kopieren einer Tabelle ein Write-Lock auf diese legen.

[kajo0011]

Fazit: mysql NUR mittels mysqldump sicherm oder?

[majortermi]

Fazit: mysql NUR mittels mysqldump sicherm oder?

mysqldump ist schon nicht schlect, kann aber auch nicht die Integrität der Daten sicherstellen (Transaktionen - okay, das ist bei MySQL eh so ein Thema). Sicher ist man bei MySQL nur, wenn man _alle_ Tabellen einer Datenbank lockt und sie dann kopiert.

[kajo0011]

Also:

Code: Select all

mysqldump --opt --all-databases >mysql.sql

[nap-d]

Also:

Code: Select all

mysqldump --opt --all-databases >mysql.sql

Sollte da nicht noch ein

Code: Select all

--lock-tables

rein, zwecks der Datenkonsistenz?

[bernostern]

Hi,
--opt beinhaltet auch --lock-tables

Gruß,
Bern

[walter12]

Und was ist, denn die Datenbank defekt ist ? Ich will ja keine defekte Datenbank sichern. Dies könnte man ja eigentlich mit überprüfen oder ?