1. DBMS ● What are they? ● Why used ● Examples? – Oracle – Access – MySQL – Postgres – SQLServer – Sqlite

2. Backups ● It is important to back up your databases so that you can recover your data and be up and running again in case problems occur, such as system crashes, hardware failures, or users deleting data by mistake. Backups are also essential as a safeguard before upgrading a MySQL installation, and they can be used to transfer a MySQL installation to another system or to set up replication slave servers.

3. Backup Types ● Logical vs Physical – Logical: save information represented as logical database structure. ● Done by querying the MySQL server to obtain structure and content info ● Slower, has to access info and convert to logical format ● Output is larger ● No logs or configs sotred ● Not machine dependent – highly portable ● Server doesn't need to be taken offline to back it up ● Mysqldump – Must use –skip-lock-tables option on mysql.cs.dixie.edu

4. Backup Types (cont) – Physical: raw copies of directories and files that store db contents. ● Backs up exact copies of db dir and files. ● Faster than logical, only copies, no conversion is necessary. ● Output is more compact ● Can include log info ● Portable only to machines with similar hardware ● Can be performed when MySQL is NOT running, otherwise have to appropriately lock db. ● Cp, scp, tar, rsync, mysqlhotcopy

5. Online vs offline backups ● Online – while server is running – Doesn't necessarily impact other clients – Need to ensure appropriate locking so that integrity isn't compromised. ● Offline – while server is stopped – Unavailable to clients – Don't need to worry about modifications by clients at same time

6. Backups ● Local vs remote – duh! ● Full vs. incremental

7. Backups (how-to) ● Get a sample database that we can work with: – http://it4200.cs.dixie.edu/sampledatabase.zip ● Hot – individual text file backup – select * INTO OUTFILE 'customers1.txt' from customers; – Saved in /var/lib/mysql/ ● Mysqldump is much more exciting – mysqldump -u root -p classicmodels > out.txt – Man mysqldump

8. The binary log ● Edit my.cnf binlog directory ● insert into employees values(29, 'francom', 'joe', '123', 'j@j.com', '333',1,'manager'); ● Mysqlbinlog ● The binary log contains “events” that describe database changes such as table creation operations or changes to table data. It also contains events for statements that potentially could have made changes (for example, a DELETE which matched no rows). The binary log also contains information about how long each statement took that updated data ● Binary log is used for replication (later) ● After backup has been restored, events in binlog that were recorded after the backup was made are re-executed (bringing db up-to-date) ● More when we do replication

9. More on Binary Log ● http://dev.mysql.com/doc/refman/5.5/en/binary-log.html http://dev.mysql.com/doc/refman/5.5/en/binary-log.html

10. Establishing a backup policy ● To be useful should be scheduled regularly ● Full backups are necessary, but it is not always convenient to create them. They produce large backup files and take time to generate. They are not optimal in the sense that each successive full backup includes all data, even that part that has not changed since the previous full backup. It is more efficient to make an initial full backup, and then to make incremental backups. The incremental backups are smaller and take less time to produce. The tradeoff is that, at recovery time, you cannot restore your data just by reloading the full backup. You must also process the incremental backups to recover the incremental changes. ● To make incremental backups, we need to save the incremental changes. (this is managed by the binary log) ● Each time mysql restarts is starts a new log file with next number in sequence. – Flush logs, will also start a new logfile ● mysqldump --single-transaction --flush-logs --master-data=2 \ ● --all-databases > backup_sunday_1_PM.sql

11. Backups ● Restoring – mysql < backup_sunday_1_PM.sql (to restore full backup) – mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql (to restore incremental backups)

12. Backup Strategy Summary ● always run the MySQL server with the --log-bin option, or even --log- bin=log_name, where the log file name is located on some safe media different from the drive on which the data directory is located. If you have such safe media, this technique can also be good for disk load balancing (which results in a performance improvement). ● Make periodic full backups, using the mysqldump command shown earlier in Section 6.3.1, “Establishing a Backup Policy”, that makes an online, nonblocking backup. ● Make periodic incremental backups by flushing the logs with FLUSH LOGS or mysqladmin flush-logs.

13. Binary Logs ● View all bin log files; – SHOW BINARY LOGS; ● Name of current bin log; – SHOW MASTER STATUS;