Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Backup recovery with PostgreSQL

470 views

Published on

Logical backup with pg_dump and physical with log shipping and streaming replication

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Backup recovery with PostgreSQL

  1. 1. Backup and recovery with PostgreSQL Mostly harmless Federico Campoli Brighton PostgreSQL Users Group 13 June 2016 Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 1 / 58
  2. 2. Table of contents 1 Like tears in the... ACID 2 Crash, Recovery and their band of merry men 3 Point in Time and Recovery in space 4 A heap of broken WALs 5 And now for something completely different 6 Wrap up Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 2 / 58
  3. 3. Like tears in the... ACID Table of contents 1 Like tears in the... ACID 2 Crash, Recovery and their band of merry men 3 Point in Time and Recovery in space 4 A heap of broken WALs 5 And now for something completely different 6 Wrap up Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 3 / 58
  4. 4. Like tears in the... ACID Like tears in the... ACID Wikipedia, By Source, Fair use Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 4 / 58
  5. 5. Like tears in the... ACID Failure is not an option... The hardware is subject to faults. Losing the storage makes the data infrastructure inaccessible, maybe for good. Human errors, like not filtered delete or table drop can destroy your data. A solid backup strategy is the best protection when the disaster strikes. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 5 / 58
  6. 6. Like tears in the... ACID Logical vs physical Backup can be implemented in different ways. We’ll check the two popular options available in PostgreSQL. The logical backup with pg dump The physical backup with the PITR or standby servers Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 6 / 58
  7. 7. Like tears in the... ACID pg dump at glance pg dump is the PostgreSQL’s utility for saving consistent backups Supports local or remote connections Doesn’t affects the normal database activity It blocks the DML for the relations backed up Supports the data dump in multiple jobs (9.3+) Can save partial backups (Warning!) Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 7 / 58
  8. 8. Like tears in the... ACID Under the hood When started for a full backup pg dump queries the PostgreSQL’s system catalogue. In particular Starts a new read only transaction If launched in parallel jobs exports the snapshot Builds the DML from saved relations Dumps the DML and the data Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 8 / 58
  9. 9. Like tears in the... ACID The backup formats When specified the switch -F is possible to save the data in several formats p Plain format c Custom format d Directory format Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 9 / 58
  10. 10. Like tears in the... ACID The plain format Outputs a plain SQL script Default output to stdout!!!! No compression Suitable for direct load using a client like psql Not flexible at restore time md5 checksum simple Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 10 / 58
  11. 11. Like tears in the... ACID The custom format Outputs in binary file Compression Requires pg restore to load the data into a database Supports parallel restore only Very flexible at restore time md5 checksum simple Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 11 / 58
  12. 12. Like tears in the... ACID The directory format Outputs in a directory with a binary toc file The table’s data is saved in gzipped files Compression Requires pg restore to load the data into a database Supports parallel backup and restore Very flexible at restore time md5 checksum can be tricky Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 12 / 58
  13. 13. Crash, Recovery and their band of merry men Table of contents 1 Like tears in the... ACID 2 Crash, Recovery and their band of merry men 3 Point in Time and Recovery in space 4 A heap of broken WALs 5 And now for something completely different 6 Wrap up Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 13 / 58
  14. 14. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men Montparnasse derailment Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 14 / 58
  15. 15. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men The word ACID is an acronym for Atomicity, Consistency, Isolation and Durability. An ACID compliant database ensures those rules are enforced at any time. Atomicity requires that each transaction be “all or nothing” The consistency property ensures that any transaction will bring the database from one valid state to another The isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially The durability property ensures that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors. Source Wikipedia Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 15 / 58
  16. 16. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men PostgreSQL implements the durability using the Write Ahead Logging. When a page is updated in the volatile memory a so called xlog record is written on the write ahead log for the crash recovery. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 16 / 58
  17. 17. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 17 / 58
  18. 18. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 18 / 58
  19. 19. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 19 / 58
  20. 20. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men The WAL segments are stored in the directory $PGDATA/pg xlog Each segment is usually 16 MB When the segment is full then PostgreSQL switches to another segment The number of segments is managed by PostgreSQL Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 20 / 58
  21. 21. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men The page in memory which is updated but not yet written on the data area is called dirty The actual write happens either when the background writer processes the page or at the checkpoint The checkpoint frequency is controlled by the parameters checkpoint timeout and checkpoint segments Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 21 / 58
  22. 22. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men When the checkpoint happens All the dirty pages in the shared buffer are written to disk The control file is updated with the last recovery location The WAL files are recycled or removed Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 22 / 58
  23. 23. Crash, Recovery and their band of merry men Crash, Recovery and their band of merry men If the server crashes with dirty pages in memory At the startup the control file is accessed to get the last recovery location The WAL files are scanned and all the XLOG records are replayed A checkpoint is triggered at the end of the recovery Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 23 / 58
  24. 24. Point in Time and Recovery in space Table of contents 1 Like tears in the... ACID 2 Crash, Recovery and their band of merry men 3 Point in Time and Recovery in space 4 A heap of broken WALs 5 And now for something completely different 6 Wrap up Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 24 / 58
  25. 25. Point in Time and Recovery in space Point in Time and Recovery in space Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 25 / 58
  26. 26. Point in Time and Recovery in space Point in Time and Recovery in space When the server switches to another wal file the old one becomes available for eviction or recycling at the next checkpoint. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 26 / 58
  27. 27. Point in Time and Recovery in space Point in Time and Recovery in space When the server switches to another wal file the old one becomes available for eviction or recycling at the next checkpoint. If we save this file in another location and take an inconsistent copy of the data area, we can reconstruct the server physical copy. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 26 / 58
  28. 28. Point in Time and Recovery in space Point in Time and Recovery in space When the server switches to another wal file the old one becomes available for eviction or recycling at the next checkpoint. If we save this file in another location and take an inconsistent copy of the data area, we can reconstruct the server physical copy. So simple? Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 26 / 58
  29. 29. Point in Time and Recovery in space Point in Time and Recovery in space When the server switches to another wal file the old one becomes available for eviction or recycling at the next checkpoint. If we save this file in another location and take an inconsistent copy of the data area, we can reconstruct the server physical copy. So simple? Not exactly. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 26 / 58
  30. 30. Point in Time and Recovery in space Point in Time and Recovery in space The control file is constantly written and therefore is not a source of truth for the last checkpoint location. The wal file does not contains the transaction commit status nor the vacuum operations. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 27 / 58
  31. 31. Point in Time and Recovery in space Point in Time and Recovery in space The control file is constantly written and therefore is not a source of truth for the last checkpoint location. The wal file does not contains the transaction commit status nor the vacuum operations. The configuration file needs some adjustments. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 27 / 58
  32. 32. Point in Time and Recovery in space Point in Time and Recovery in space The control file is constantly written and therefore is not a source of truth for the last checkpoint location. The wal file does not contains the transaction commit status nor the vacuum operations. The configuration file needs some adjustments. Changing the following parameters requires a server restart. archive mode set to ’on’ Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 27 / 58
  33. 33. Point in Time and Recovery in space Point in Time and Recovery in space The control file is constantly written and therefore is not a source of truth for the last checkpoint location. The wal file does not contains the transaction commit status nor the vacuum operations. The configuration file needs some adjustments. Changing the following parameters requires a server restart. archive mode set to ’on’ wal level set to archive, hot standby or logical Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 27 / 58
  34. 34. Point in Time and Recovery in space Point in Time and Recovery in space Changing archive command requires only a server reload. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 28 / 58
  35. 35. Point in Time and Recovery in space Point in Time and Recovery in space archive_command = ’test ! -f /pg_archive/%f && cp %p /pg_archive/%f’ Each time a WAL is switched the archive command is executed to save the file. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 29 / 58
  36. 36. Point in Time and Recovery in space Point in Time and Recovery in space Start the backup with postgres =# SELECT pg_start_backup (’PITR ’, ’t’); pg_start_backup -- --------------- 0/3000028 (1 row) The command issues a checkpoint and creates the file backup label in the data area. In this file it’s written the recovery WAL’s start location. START WAL LOCATION: 1/28000028 (file 000000010000000100000028) CHECKPOINT LOCATION: 1/28000060 BACKUP METHOD: pg_start_backup BACKUP FROM: master START TIME: 2015-11-22 17:47:23 UTC LABEL: PITR Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 30 / 58
  37. 37. Point in Time and Recovery in space Point in Time and Recovery in space Save the running cluster’s data area and all the tablespaces rsync copy tar cpio Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 31 / 58
  38. 38. Point in Time and Recovery in space Point in Time and Recovery in space Tell the server the backup is complete with pg stop backup(); postgres =# SELECT pg_stop_backup (); NOTICE: pg_stop_backup complete , all required WAL segments have been archived pg_stop_backup -- -------------- 1/2 C0000F0 (1 row) The command deletes the backup label and switches the current log file in order archive all the required segments. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 32 / 58
  39. 39. Point in Time and Recovery in space Point in Time and Recovery in space If a recovery is needed, we shall restore the data directory. Then, inside the data area, we must create a text file called recovery.conf. The file is used to set the recovery strategy. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 33 / 58
  40. 40. Point in Time and Recovery in space Point in Time and Recovery in space If a recovery is needed, we shall restore the data directory. Then, inside the data area, we must create a text file called recovery.conf. The file is used to set the recovery strategy. restore_command = ’cp /pg_archive/%f %p’ This command does the opposite of the archive command set previously. It’s the copy command for restoring the archived WALs into the pg xlog. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 33 / 58
  41. 41. Point in Time and Recovery in space Point in Time and Recovery in space recovery target = ’immediate’ This parameter specifies that recovery should end as soon as a consistent state is reached, i.e. as early as possible. When restoring from an online backup, this means the point where taking the backup ended. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 34 / 58
  42. 42. Point in Time and Recovery in space Point in Time and Recovery in space recovery target time (timestamp) This parameter specifies the time stamp up to which recovery will proceed. The precise stopping point is also influenced by recovery target inclusive. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 35 / 58
  43. 43. Point in Time and Recovery in space Point in Time and Recovery in space recovery target inclusive (boolean) Specifies whether to stop just after the specified recovery target (true), or just before the recovery target (false). Applies when either recovery target time or recovery target xid is specified. This setting controls whether transactions having exactly the target commit time or ID, respectively, will be included in the recovery. Default is true. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 36 / 58
  44. 44. Point in Time and Recovery in space Point in Time and Recovery in space The PITR enforces the disaster recovery. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 37 / 58
  45. 45. Point in Time and Recovery in space Point in Time and Recovery in space The PITR enforces the disaster recovery. Which comes very handy if, for example, somebody drops a table by accident. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 37 / 58
  46. 46. Point in Time and Recovery in space Point in Time and Recovery in space The PITR enforces the disaster recovery. Which comes very handy if, for example, somebody drops a table by accident. Alongside with this Copyright Tim Avatar Bartel Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 37 / 58
  47. 47. A heap of broken WALs Table of contents 1 Like tears in the... ACID 2 Crash, Recovery and their band of merry men 3 Point in Time and Recovery in space 4 A heap of broken WALs 5 And now for something completely different 6 Wrap up Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 38 / 58
  48. 48. A heap of broken WALs A heap of broken WALs Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 39 / 58
  49. 49. A heap of broken WALs A heap of broken WALs As soon as the recovery target is reached the server becomes a standalone instance generating a new timeline. The recovery.conf can also be configured in order to set the server in continuous recovery. In this configuration we are talking of a standby server. The standby server helps to enforce the high availability because replays the master’s changes in almost real time. The standby server can be warm or hot standby. The latter configuration allows the read only queries. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 40 / 58
  50. 50. A heap of broken WALs A heap of broken WALs Standby server’s minimal recovery.conf standby_mode = ’on’ restore_command = ’cp /pg_archive/%f %p’ archive_cleanup_command = ’pg_archivecleanup /pg_archive %r’ Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 41 / 58
  51. 51. A heap of broken WALs A heap of broken WALs Slave’s hot standby configuration hot_standby=’on’ max_standby_archive_delay=’30s’ Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 42 / 58
  52. 52. A heap of broken WALs A heap of broken WALs Using the wal shipping for the standby have some limitations. is not realtime Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 43 / 58
  53. 53. A heap of broken WALs A heap of broken WALs Using the wal shipping for the standby have some limitations. is not realtime the network can be an issue Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 43 / 58
  54. 54. A heap of broken WALs A heap of broken WALs Using the wal shipping for the standby have some limitations. is not realtime the network can be an issue archive corruption leads to a broken standby server Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 43 / 58
  55. 55. A heap of broken WALs A heap of broken WALs Using the wal shipping for the standby have some limitations. is not realtime the network can be an issue archive corruption leads to a broken standby server the WAL files are stored in the slave’s archive and then copied into to the pg xlog Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 43 / 58
  56. 56. And now for something completely different Table of contents 1 Like tears in the... ACID 2 Crash, Recovery and their band of merry men 3 Point in Time and Recovery in space 4 A heap of broken WALs 5 And now for something completely different 6 Wrap up Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 44 / 58
  57. 57. And now for something completely different And now for something completely different Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 45 / 58
  58. 58. And now for something completely different And now for something completely different PostgreSQL 9.0 introduced the streaming replication which is physical block replication over a database connection. the WALs are streamed using a database connection in almost realtime Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 46 / 58
  59. 59. And now for something completely different And now for something completely different PostgreSQL 9.0 introduced the streaming replication which is physical block replication over a database connection. the WALs are streamed using a database connection in almost realtime the WALs are saved in the pg xlog Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 46 / 58
  60. 60. And now for something completely different And now for something completely different PostgreSQL 9.0 introduced the streaming replication which is physical block replication over a database connection. the WALs are streamed using a database connection in almost realtime the WALs are saved in the pg xlog it supports the synchronous slaves Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 46 / 58
  61. 61. And now for something completely different And now for something completely different PostgreSQL 9.0 introduced the streaming replication which is physical block replication over a database connection. the WALs are streamed using a database connection in almost realtime the WALs are saved in the pg xlog it supports the synchronous slaves replication slots simplifies the streaming replication only slaves Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 46 / 58
  62. 62. And now for something completely different And now for something completely different On the master add an user with the replication privilege CREATE ROLE usr_replication WITH REPLICATION PASSWORD ’EiHohG2z ’ LOGIN; Update the master’s postgresql.conf max_wal_senders = 2 #requires restart wal_level = hot_standby #requires restart wal_keep_segments = 32 Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 47 / 58
  63. 63. And now for something completely different And now for something completely different Add an entry in the master’s pg hba.conf for the “virtual” database replication host replication usr_replication 192.168.0.20/22 md5 Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 48 / 58
  64. 64. And now for something completely different And now for something completely different Add the connection info the slave’s recovery.conf primary_conninfo=’dbname=replication user=usr_replication host=pg_master password=EiHohG2z port=5432’ Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 49 / 58
  65. 65. And now for something completely different And now for something completely different Restarting the slave it will reply the WAL files from the archive like a normal PITR/standby. Only when there are no more WALs available to restore the slave will connect to the master using the connection string in primary conninfo. If the connection succeeds the slave will start streaming the WAL files from the master’s pg xlog directly into its own pg xlog. Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 50 / 58
  66. 66. Wrap up Table of contents 1 Like tears in the... ACID 2 Crash, Recovery and their band of merry men 3 Point in Time and Recovery in space 4 A heap of broken WALs 5 And now for something completely different 6 Wrap up Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 51 / 58
  67. 67. Wrap up pg dump in a nutshell Saves statical snapshots of the database It’s logical The restore can take long time Doesn’t saves the data when the backup in progress It’s very mature and reliable Disaster recovery Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 52 / 58
  68. 68. Wrap up PITR in a nutshell Saves an on going backup It’s physical The restore can be very fast Saves the entire cluster It’s reliable Disaster recovery Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 53 / 58
  69. 69. Wrap up Standby in a nutshell The server is up and running replaying the changes It’s physical The recovery is almost immediate Saves the entire cluster It’s reliable Can be used for load balancing High availability Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 54 / 58
  70. 70. Wrap up Questions? Questions? Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 55 / 58
  71. 71. Wrap up Contacts and license Twitter: 4thdoctor scarf Blog:http://www.pgdba.co.uk Brighton PostgreSQL Meetup: http://www.meetup.com/Brighton-PostgreSQL-Meetup/ This document is distributed under the terms of the Creative Commons Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 56 / 58
  72. 72. Wrap up Credits Montparnasse derailment: Source Wikipedia, Public Domain, credited to the firm Levy & fils Flail picture: Copyright Tim Avatar Bartel - The flail belongs to his girlfriend The two doctors: Copyright Federico Campoli The phantom’s playground: Copyright Federico Campoli The pedestrian seagull: Copyright Federico Campoli Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 57 / 58
  73. 73. Wrap up Backup and recovery with PostgreSQL Mostly harmless Federico Campoli Brighton PostgreSQL Users Group 13 June 2016 Federico Campoli (Brighton PostgreSQL Users Group) Backup and recovery with PostgreSQL 13 June 2016 58 / 58

×