Creating a complete disaster recovery strategy
0 likes•174 views
This document is a presentation by Jens Bollmann at MariaDB Corporation, focusing on backup and recovery strategies essential for data integrity and disaster recovery. It emphasizes the importance of having a robust backup strategy and highlights common tools and advanced strategies for effective data recovery. The presentation also discusses potential data loss causes and tactics to safeguard against them, alongside demonstrations of specific recovery techniques.
Creating a complete disaster recovery strategy
- 1. MARIADB PRESENTATION JENS BOLLMANN Instructor and Consultant MariaDB Corporation
- 2. ● Consulting worldwide ● Performance Tuning ● High Availability ● Architecture and Design ● Security ● Instructor worldwide ● Entire MariaDB curriculum ● Certification preparation WHOAMI
- 3. Nobody needs backups. The only thing we need is recovery. —Manager seeking for a new challenge ...
- 4. Your own employees are the greatest cause of data loss, beating even malicious attacks by hackers or nature impacts on Data Centers. — DBA
- 5. Have a backup and do not argue about the costs→ there are tons of examples from companies failed to bankruptcy because of a missing backup & RECOVERY strategy —Wise DBA
- 6. 1. What data is important 2. How much data can my business afford in case of a loss 3. How long can I stand a downtime 4. Is my backup protected outside my company and retrieval easy and tested → seek for access and time 5. Do we have a proper recovery tested regularly Common mistakes
- 7. Backup Commonly used tools with MariaDB – mysqldump slow/portable – mariabackup hot ● supports encryption! – mydumper * individual tables * github
- 8. Backup Commonly used tools – mysqldump -A | gzip > dumpfile.sql.gz – mariabackup ● mariabackup - - backup - - target-dir=/backupfolder – Make sure backup is stored somewhere else in different locations
- 9. Recovery Commonly used tools – mysql < dumpfile.sql – zcat dumpfile.sql.gz | mysql – mariabackup (supports encryption!) ● mariabackup - - prepare ● mariabackup - - copy-back ● chown to mariadb owner
- 10. HELPER BINLOG → PITR Synchronize your Backup with Binary Log
- 11. HELPER BINLOG → PITR – mysqldump - - master-data=2 – mysqldump - - gtid – mariabackup Have the information preserved with the dumpfile or with separate files – in mariabackup the files contain the binary log filename and position or GTID
- 12. HELPER BINLOG → PITR Backup binlog.000001binlog.000001 binlog.000002binlog.000002 PebCaS issue, e.g. DROP DATABASE hr;
- 13. PITR Demo • Create a backup synced with binary log • Write data • Corrupt database or delete table • Write data • IDENTIFY issue reported by users • STOP OPERATION • Analyze and develop recovery strategy • Restore youngest backup • Apply binary logs with stop and start position • START OPERATION • DONE
- 14. HELPER BINLOG → Live demo Backup binlog.000001binlog.000001 binlog.000002binlog.000002
- 15. ADVANCED BACKUP STRATEGIES – mariabackup ● socat stream to backup servers – Different geo location – Used in Cluster setups ● gzip
- 16. ADVANCED BACKUP STRATEGIES – Delayed replication – Szenario: 20 minutes old data CHANGE MASTER TO master_delay=1200; – On human errors ● Switchover to slave ● Apply copied binlogs to that slave
- 17. HELPER BINLOG → FLASHBACK Rollback in time – mysqlbinlog - - flashback
- 18. Flashback Live Demo • Run mysqlbinlog in flashback mode • It will process the binary logs in reverse order • INSERTs becomes DELETEs • DELETEs becomes INSERTs • UPDATE becomes UPDATE of previous data
- 19. Actual VERSIONS OF MariaDB – Backup is done in stages ● InnoDB first and hot ● Other non transactional Storage engines require some locking ● Apply changes in InnoDB after other storage engine have been unlocked o
- 20. THANK YOU!