MySQL Absicherung und Datensicherung

  • 2,589 views
Uploaded on

Talk about MySQL Backup and Security, presented at the amoocon 2009 in Rostock, Germany

Talk about MySQL Backup and Security, presented at the amoocon 2009 in Rostock, Germany

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,589
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
15
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1 Sun Microsystems Methoden zur Absicherung und Datensicherung eines MySQL- Servers Lenz Grimmer MySQL Community Relations Manager
  • 2. 2 Übersicht • Verbesserung der Server-Sicherheit > Integrierte Funktionalität > Auf Betriebssystem-Ebene • MySQL Datensicherung > physikalisch vs. logisch > Methoden und Werkzeuge
  • 3. 3 MySQL-Absicherung • Wichtige Arbeitsschritte nach Erstinstallation • Sicherheit der Standardinstallation bereits relativ hoch • Zusätzliche Sicherungsmaßnahmen des Betriebssystems flankieren die im Server enthaltenen Funktionen http://dev.mysql.com/doc/refman/5.0/en/security.html
  • 4. 4 Benutzerkonten • Kennwort für den root-User $ mysql -u root mysql mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password'); • Entfernen des anonymen Benutzers • Entfernen der test-Datenbank • Script: mysql_secure_installation • Konten: nur die erforderlichen • Privilegien: nur die notwendigen
  • 5. 5 Prüfung der Zugriffsrechte • Verbindungsaufbau > Server überprüft anhand der user-Tabelle, ob ein passender Eintrag für username, host und passwort existiert • SQL-Abfrage > Server überprüft Privilegien anhand der user, db, tables_priv and column_privs Tabellen http://dev.mysql.com/doc/refman/5.0/en/privilege-system.html
  • 6. 6 MySQL-Zugangskontrolle Query true false db true Query executed Permission denied false columns_priv false tables_priv false user true true
  • 7. 7 Sicherheitsfunktionen • Nützliche Optionen in my.cfg: > bind-address – lauscht nur am einem TCP- Interface (z.B. 127.0.0.1) > skip-networking – Kommunikation nur lokal (via socket-Datei) • Wichtige SQL-Anweisungen: SHOW GRANTS, SET PASSWORD, GRANT/REVOKE • PROCESS/SUPER/FILE Privilegien minimieren
  • 8. 8 Weitere Hinweise • Keine Benutzerkennwörter im Klartext in Tabellen speichern • MD5() oder SHA1(), nicht PASSWORD() • Verschlüsselung (SSL, SSH, VPN) • LOAD DATA LOCAL deaktivieren: --local-infile=0 • Nie mysqld als root-Benutzer ausführen • History-Datei ~/.mysql_history absichern oder löschen • MySQL root-User umbenennen
  • 9. 9 Views & Stored Procedures • VIEWs können Zugriff auf bestimmte Spalten regeln > http://dev.mysql.com/doc/refman/5.0/en/views.html • Stored Procedures schirmen die realen Tabellen vor direkten Zugriffen durch Anwender und Applikationen ab > http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html • Seit MySQL 5.0 enthalten
  • 10. 10 Absicherung auf OS-Ebene • Zugriff auf das Datenverzeichnis beschränken (chown/chmod) > Tabellen und Log-Dateien schützen • Keine Shell-Konten auf dem DB-Server • Kein direkter Zugriff auf Port 3306 aus dem Internet! • Firewall/DMZ/iptables • SELinux, AppArmor, RBAC • chroot(), Zones/Container, VMs
  • 11. 11 Datensicherung • Notwendigkeit > Hardware-Ausfall > Anwender- oder Applikationsfehler • Zu sichernde Daten > Datenbankinhalte > Log-Dateien • Weitere Aspekte > Sicherungszeitpunkt > Ort der Sicherung und Aufbewahrung
  • 12. 12 Wann werden Sicherungen benötigt? • Datenverlust durch Hardwarefehler > Absturz wg. Hardwareschaden > Festplattenausfall > Defekte Hardware • Anwender- und Applikationsfehler > DROP TABLE oder DELETE FROM ohne WHERE-Klausel > Development vs. Production DB > Öffnen der Tabellendateien mit der falschen Anwendung
  • 13. 13 Was sollte gesichert werden? • Datenbankinhalte > Für komplette Sicherungen > Logisch oder phyikalisch • Log-Dateien > Für inkrementelle Sicherungen > Wiederherstellungszeitpunkte (Point in time recovery) • Konfigurationsdateien > /etc/my.cnf > Cron-Jobs
  • 14. 14 Zeitpunkt der Datensicherung • Regelmäßig • Außerhalb der Lastspitzen • Wenig veränderliche Daten weniger häufig
  • 15. 15 Speicherung der Sicherungskopien • Auf dem DB-Server > Besser nicht! > Zumindest auf einem separaten Dateisystem/ Volume oder Laufwerk • Kopiert auf einen anderen Server > Onsite oder offsite • Sicherung/Archivierung auf Band/Wechselplatte • An verteilten Orten
  • 16. 16 Modulare Speicher-Engine-Architektur
  • 17. 17 MySQL Datenverzeichnis • Alle Datenbanken und Logfiles werden standardmäßig hier gespeichert • Ort abhängig von der MySQL distribution (einkompilierter Wert): > /usr/local/mysql/data (tarball) > /var/lib/mysql (RPM) • Mit --datadir=/pfad/zum/datadir anpaßbar • SHOW VARIABLES LIKE 'datadir'; • InnoDB: innodb_data_home_dir
  • 18. 18 Das Binärlog • Speichert alle datenverändernden SQL- Anweisungen (DML) z.B. CREATE, INSERT, DELETE, DROP, UPDATE • Zweck: > Erleichtert Datenwiederherstellung > Replikation • Enthält zusätzliche Informationen (Zeitstempel, Laufzeit) • Binär codiert, mysqlbinlog zum decodieren • Aktiviert mit --log-bin[=datei]
  • 19. 19 Log-Management • Server rotiert die Logs • Log-Indexdatei verzeichnet alle Logs • SHOW MASTER LOGS – listet alle auf dem Server vorhandenen logs • FLUSH LOGS – rotiert logs • RESET MASTER – löscht alle binärlogs • PURGE MASTER – löscht alle binärlogs bis zu einem best. Zeitpunkt
  • 20. 20 Sicherungsmethoden • logisch: SQL-Anweisungen • physikalisch: Tabellendateien • vollständig vs. inkrementell > Aktivieren des Binärlogs > Zeitpunktbezogene Wiederherstellung
  • 21. 21 Gängige MySQL-Sicherungspraktiken • mysqldump > Vollständige Sicherung $ mysqldump mydb > mydb.20050925.sql > Struktur und/oder Daten als SQL- Anweisungen: CREATE TABLE, INSERT > Einzelne Tabellen oder Datenbanken möglich > portabel, aber unhandlich bei großen Datenmengen • Mit anderen Unix-Werkzeugen kombinierbar (Piping) $ mysqldump ­­opt world | mysql ­h remote.host.com world
  • 22. 22 mysqldump - Tipps • --lock-all-tables – nützlich für konsistente MyISAM-Backups > Aber sperrt alle DML-Anweisungen • --flush-logs – synchronisiert das Binärlog (Checkpointing)
  • 23. 23 Sicherung von InnoDB-Tabellen • mysqldump --single-transaction erstellt konsistente Sicherungskopie ohne Locking • Physikalische Sicherung > MySQL-Server herunterfahren! > Datenfiles, InnoDB log-Dateien, .frm-Dateien sichern > Server wieder starten
  • 24. 24 XtraBackup / Maatkit • https://launchpad.net/percona-xtrabackup • Online-Backup für InnoDB • In my.cnf: > [xtrabackup] target_dir = /home/backups • Backup-Kommando: > xtrabackup –backup • http://maatkit.org/ • Multi-threaded Perl wrapper scripts > mk-parallel-dump / mk-parallel-restore
  • 25. 25 Weitere Sicherungsmöglichkeiten • Replikation > Sicherung erfolgt auf Slave > Bonus: erhöhte Verfügbarkeit • Dateisystem-Snapshots > „semi-hot“ > Linux: LVM (mylvmbackup) > Solaris: ZFS (mysql-snapback) • MySQL 6.0: Online Backup API http://forge.mysql.com/wiki/OnlineBackup
  • 26. 26 Backups über Dateisystem-Snapshots • Bequeme und schnelle Lösung zur unterbrechungsfreien Sicherung vollständiger Datenbanken • Geringer Platzbedarf des LVM-Snapshots (10-15% reichen üblicherweise aus) • Backup der Dateien auf dem Snapshot Volumen mit beliebigen Tools • Beeinträchtigung der I/O Performance (Linux LVM)
  • 27. 27 Linux LVM Snapshot-Erzeugung Funktionsprinzip: mysql> FLUSH TABLES WITH READ LOCK $ lvcreate -s –-size=<size> --name=backup <LV> mysql> UNLOCK TABLES $ mount /dev/<VG>/backup /mnt $ tar czvf backup.tar.gz /mnt/* $ umount /mnt $ lvremove /dev/<VG>/backup
  • 28. 28 Das mylvmbackup-Script • Script zur schnellen Erzeugung von MySQL- Backups mit LVM-Snapshots • Snapshots werden in ein temporäres Verzeichnis eingehängt, die Daten werden mit tar,rsync oder rsnap gesichert • Archivnames mit Zeitstempeln ermöglichen wiederholte Backup-Läufe ohne Überschreiben • Kann vor dem Backup InnoDB- Wiederherstellung auf dem Snapshot durchführen • Benötigt Perl, DBI and DBD::mysql • http://www.lenzg.net/mylvmbackup/
  • 29. 29 Werkzeuge • Shell: cp, tar, cpio, gzip, zip, cron • rsync, unison, rsnapshot, rdiff • afbackup, Amanda/Zmanda, Bacula • Nicht auf live-Daten anwenden! (ma.gnolia.com anyone?)
  • 30. 30 Wiederherstellung • Letzte vollständige Sicherungskopie (+ binäre Logdatei) • Einspielen des SQL-Dumps oder Kopieren der gesicherten Tabellendateien • Wiederherstellung eines bestimmten Zeitpunkts (point-in-time recovery) durch Zeitstempel im Binärlog möglich
  • 31. 31 Beispiel Wiederherstellung • Letzte vollständige Sicherung einspielen: $ mysql < backup.sql • Einspielen der inkrementellen Änderungen seit der letzten vollständigen Sicherung: $ mysqlbinlog hostname-bin.000001 | mysql
  • 32. 32 Vergleich der Sicherungsmethoden • Portabilität (SQL Dumps vs. Tabellendateien) • Geschwindigkeit, Speicherbedarf • Overhead und Beeinträchtigung des Betriebs
  • 33. 33 Sicherungsstrategien • Regelmäßige Durchführung • Binärlog aktivieren • Log-Dateien synchronisieren (FLUSH LOGS) • SQL-Dumps konsistent und verständlich benennen (z.B. mit Zeitstempel im Dateinamen) • Aufbewahrung der Sicherungen auf anderen Dateisystemen
  • 34. 34 Generelle Backup-Hinweise • Binärlogs auf einem anderen Laufwerk/Dateisystem ablegen > Verbesserte Performance > Vermeidet vollständigen Datenverlust • Backups auf Vollständigkeit/Korrektheit überprüfen • Prozeduren und Zeitpläne für Backups und Wiederherstellung festlegen • Testen, ob sie auch wirklich funktionieren!
  • 35. 35 Vielen Dank! Fragen, Kommentare, Anregungen? Lenz Grimmer <lenz@sun.com>