Anschliessend geht es mir besser
- Ersteller sd12
- Erstellt am
Jürgen Auer
Legendäres Mitglied
QUOTE (sd12 @ So 22.4.2007, 16:56)Aber ein inkrementelles Image der ganzen Maschine...
Das sichert doch normalerweise nicht die Datenbank-Dateien. Und selbst wenn, dann sind diese doch normalerweise nicht als reales Backup geeignet?
Richtige Datenbank-Backups laufen bei mir jede Nacht durch - und anschließend werden die per Maschinen-Backup raustransportiert und zwanzig Tage lang aufbewahrt.
Und - ähm: Bei 'guten Datenbank-Systemen' stört das doch nicht. Da machst Du nach dem Fehler noch ein Backup vom Log, stellst anschließend die DB und das Log bis unmittelbar vor dem Fehler wieder her und verwirfst den Rest. Ok, das geht nur, falls kein aktueller Betrieb drauf ist - aber wir haben Wochenende.
Das sichert doch normalerweise nicht die Datenbank-Dateien. Und selbst wenn, dann sind diese doch normalerweise nicht als reales Backup geeignet?
Richtige Datenbank-Backups laufen bei mir jede Nacht durch - und anschließend werden die per Maschinen-Backup raustransportiert und zwanzig Tage lang aufbewahrt.
Und - ähm: Bei 'guten Datenbank-Systemen' stört das doch nicht. Da machst Du nach dem Fehler noch ein Backup vom Log, stellst anschließend die DB und das Log bis unmittelbar vor dem Fehler wieder her und verwirfst den Rest. Ok, das geht nur, falls kein aktueller Betrieb drauf ist - aber wir haben Wochenende.
André Griepenburg
Legendäres Mitglied
QUOTE (jAuer @ So 22.4.2007, 18:29) Ok, das geht nur, falls kein aktueller Betrieb drauf ist - aber wir haben Wochenende.
mhh...
da würde es bei uns schon schwer werden, haben am WE und am Montag ca. 50% des wöchentlichen Besucheraufkommens
Ich mache jeden Dienstag ein Backup (vollbackup+db) und in unregelmäßigen Abständen nen db backup zusätzlich ^^
Aber ich will mir zukünftig eine vernünftige Backup-Strategie überlegen
mhh...
da würde es bei uns schon schwer werden, haben am WE und am Montag ca. 50% des wöchentlichen Besucheraufkommens
Ich mache jeden Dienstag ein Backup (vollbackup+db) und in unregelmäßigen Abständen nen db backup zusätzlich ^^
Aber ich will mir zukünftig eine vernünftige Backup-Strategie überlegen
David Cooper
Angesehenes Mitglied
Bei und wird täglich automatisch der ganze V-Server "gebackuped".
Jürgen Auer
Legendäres Mitglied
QUOTE (André Griepenburg @ So 22.4.2007, 18:16)Aber ich will mir zukünftig eine vernünftige Backup-Strategie überlegen
Einfach jede Nacht einmal.
Allerdings weiß ich nicht, ob das bei mySql so störungsfrei funktioniert wie beim MS-SqlServer. Standardmäßig ist ja mySql nicht unbedingt transaktionssicher. Beim MS-SqlServer geht das beim laufenden Betrieb ohne Störung per Job.
Da kann man auch ein Backup der Datenbank abc unter einem anderen Namen wieder einspielen und dann einzelne Datensätze per Hand in die eigentliche Datenbank reinkopieren.
QUOTE (André Griepenburg @ So 22.4.2007, 18:16)Ich mache jeden Dienstag ein Backup (vollbackup+db)
Hoffentlich umgekehrt
Einfach jede Nacht einmal.
Allerdings weiß ich nicht, ob das bei mySql so störungsfrei funktioniert wie beim MS-SqlServer. Standardmäßig ist ja mySql nicht unbedingt transaktionssicher. Beim MS-SqlServer geht das beim laufenden Betrieb ohne Störung per Job.
Da kann man auch ein Backup der Datenbank abc unter einem anderen Namen wieder einspielen und dann einzelne Datensätze per Hand in die eigentliche Datenbank reinkopieren.
QUOTE (André Griepenburg @ So 22.4.2007, 18:16)Ich mache jeden Dienstag ein Backup (vollbackup+db)
Hoffentlich umgekehrt
sd12
Legendäres Mitglied
QUOTE (DC-Forum @ So 22.4.2007, 19:18) Bei und wird täglich automatisch der ganze V-Server "gebackuped".
Das hab ich ja auch gemacht, nur bringt das nix...
Wenn dann so ein Vollidiot (wie ich) dir Daten auf der DB löscht.
Die Daten waren zwar wichtig, aber nicht so wichtig, dass ich deswegen den Server Offline genommen hätte um das Image wieder eizuspielen.
Das hab ich ja auch gemacht, nur bringt das nix...
Wenn dann so ein Vollidiot (wie ich) dir Daten auf der DB löscht.
Die Daten waren zwar wichtig, aber nicht so wichtig, dass ich deswegen den Server Offline genommen hätte um das Image wieder eizuspielen.
Sascha Ahlers
Legendäres Mitglied
QUOTE (jAuer @ So 22.4.2007, 19:14) [...] Standardmäßig ist ja mySql nicht unbedingt transaktionssicher. [...]
Das musst Du mir mal erklären, wie das gemeint ist..
Das musst Du mir mal erklären, wie das gemeint ist..
sd12
Legendäres Mitglied
QUOTE (jAuer @ So 22.4.2007, 20:14) Standardmäßig ist ja mySql nicht unbedingt transaktionssicher.
Ähm, die Transaktionssicherheit hängt von der Verwendeten Storage Engine in MySQL ab.
InnoDB bieteet Transaktionssicherheit:
http://de.wikipedia.org/wiki/InnoDB
Ähm, die Transaktionssicherheit hängt von der Verwendeten Storage Engine in MySQL ab.
InnoDB bieteet Transaktionssicherheit:
http://de.wikipedia.org/wiki/InnoDB
Jürgen Auer
Legendäres Mitglied
QUOTE (Sascha Ahlers @ So 22.4.2007, 22:47)
QUOTE (jAuer @ So 22.4.2007, 19:14) [...] Standardmäßig ist ja mySql nicht unbedingt transaktionssicher. [...]
Das musst Du mir mal erklären, wie das gemeint ist..
Es gibt MyIsam und InnoDB als Tabellentypen.
http://dev.mysql.com/doc/refman/5.0/en/innodb-overview.html
QUOTE InnoDB provides MySQL with a transaction-safe (ACID compliant) storage engine that has commit, rollback, and crash recovery capabilities. InnoDB does locking on the row level and also provides an Oracle-style consistent non-locking read in SELECT statements.
Bei MyIsam fehlen die entsprechenden Aussagen. Die deutsche 4.0 - Hilfe schreibt das explizit (CHM-Datei, Kapitel 8):
QUOTE MySQL unterstützt zwei unterschiedliche Arten von Tabellen: transaktionssichere Tabellen (InnoDB und BDB) und nicht transaktionssichere Tabellen (HEAP, ISAM, MERGE und MyISAM).
Die Standardeinstellung nutzt MyIsam - während man bei Systemen wie dem MS-SqlServer gar nicht die Möglichkeit hat, auf die Transaktionssicherheit zu verzichten.
Edit (alle Zitate CHM, 5.4.1): Und die Wirkung ist in bezug auf die Sicherung fatal: Laut 4.0-Manual ist eine Read-Lock-Tabellensperre notwendig
QUOTE Um eine konsistente Datensicherung zu erhalten, machen Sie ein LOCK TABLES auf die relevanten Tabellen, gefolgt von FLUSH TABLES für die Tabellen. See Abschnitt 7.7.2, „LOCK TABLES/UNLOCK TABLES-Syntax“. See Abschnitt 5.5.3, „FLUSH-Syntax“. Sie brauchen lediglich eine Lesesperre (Read Lock); das erlaubt anderen Threads, die Tabellen weiterhin abzufragen, während Sie eine Kopie der Dateien im Datenbank-Verzeichnis machen.
Oder:
Sie können auch einfach alle Tabellendateien (*.frm-, *.MYD- und *.MYI-Dateien) kopieren, solange der Server nicht gerade etwas aktualisiert.
Das sind Dinge, um die muß ich mich (beim MS-SqlServer) nicht kümmern, da gibt es auch keine Performance-Probleme bei der Sicherung, während mySql ausdrücklich davor warnt:
QUOTE Wenn Sie bei der Datensicherung auf Ihrem System Performance-Probleme bekommen, können Sie diese lösen, indem Sie Replikation einrichten und die Datensicherungen auf dem Slave statt auf dem Master durchführen
QUOTE (jAuer @ So 22.4.2007, 19:14) [...] Standardmäßig ist ja mySql nicht unbedingt transaktionssicher. [...]
Das musst Du mir mal erklären, wie das gemeint ist..
Es gibt MyIsam und InnoDB als Tabellentypen.
http://dev.mysql.com/doc/refman/5.0/en/innodb-overview.html
QUOTE InnoDB provides MySQL with a transaction-safe (ACID compliant) storage engine that has commit, rollback, and crash recovery capabilities. InnoDB does locking on the row level and also provides an Oracle-style consistent non-locking read in SELECT statements.
Bei MyIsam fehlen die entsprechenden Aussagen. Die deutsche 4.0 - Hilfe schreibt das explizit (CHM-Datei, Kapitel 8):
QUOTE MySQL unterstützt zwei unterschiedliche Arten von Tabellen: transaktionssichere Tabellen (InnoDB und BDB) und nicht transaktionssichere Tabellen (HEAP, ISAM, MERGE und MyISAM).
Die Standardeinstellung nutzt MyIsam - während man bei Systemen wie dem MS-SqlServer gar nicht die Möglichkeit hat, auf die Transaktionssicherheit zu verzichten.
Edit (alle Zitate CHM, 5.4.1): Und die Wirkung ist in bezug auf die Sicherung fatal: Laut 4.0-Manual ist eine Read-Lock-Tabellensperre notwendig
QUOTE Um eine konsistente Datensicherung zu erhalten, machen Sie ein LOCK TABLES auf die relevanten Tabellen, gefolgt von FLUSH TABLES für die Tabellen. See Abschnitt 7.7.2, „LOCK TABLES/UNLOCK TABLES-Syntax“. See Abschnitt 5.5.3, „FLUSH-Syntax“. Sie brauchen lediglich eine Lesesperre (Read Lock); das erlaubt anderen Threads, die Tabellen weiterhin abzufragen, während Sie eine Kopie der Dateien im Datenbank-Verzeichnis machen.
Oder:
Sie können auch einfach alle Tabellendateien (*.frm-, *.MYD- und *.MYI-Dateien) kopieren, solange der Server nicht gerade etwas aktualisiert.
Das sind Dinge, um die muß ich mich (beim MS-SqlServer) nicht kümmern, da gibt es auch keine Performance-Probleme bei der Sicherung, während mySql ausdrücklich davor warnt:
QUOTE Wenn Sie bei der Datensicherung auf Ihrem System Performance-Probleme bekommen, können Sie diese lösen, indem Sie Replikation einrichten und die Datensicherungen auf dem Slave statt auf dem Master durchführen