input/howto/postgres-backup.creole

   1 = Postgres backup =
   2
   3 Backing up postgres consists of two main pieces: backing up the WALs (write
   4 ahead logs) and regular backups of the base.  See
   5 https://www.postgresql.org/docs/9.4/static/continuous-archiving.html
   6
   7 The WALs are copied from the postgres server to the backup hosts using ssh with
   8 the {{{pg-backup-file}}} script.  Base backups are pulled on the backup hosts
   9 using {{{postgres-make-base-backups}}}.  The former requires the postgres servers
  10 be able to ssh to the backup servers, and the latter requires the postgres server
  11 listen on the network, have ssl set up correctly, access is allowed in the firewall,
  12 a postgres user with replication privileges exists and is configured to allowed
  13 to connect in {{{pg_hba}}}.
  14
  15 == server config ==
  16
  17 (2018-02 - This documentation has not really been tested since it was written -- weasel)
  18
  19 There are two possible ways to configure the server.
  20
  21 === Single cluster on a host ===
  22
  23 If there is only one cluster on the host, we can use puppet's
  24 {{{postgresql::server}}} to configure the cluster and any databases on it, see
  25 {{{modules/salsa/manifests/database.pp}}} for an example.  In particular, you
  26 want to set {{{archive_command}}} and the ssl options in {{{pg.conf}}}, as well
  27 as set {{{listen_address}}} correctly.
  28
  29 Add a {{{postgres::backup_cluster}}} stanza to get it backed up.
  30
  31 === Multiple clusters/compatibility mode ===
  32
  33 If there is potentially more than one cluster, we cannot use the puppet
  34 {{{postgresql::server}}} class.  We also use this for clusters that were
  35 initially set up without puppet.
  36
  37 * Add the server to the roles::postgresql::server class role in hiera.
  38   This will cause some scripts to be installed on the host, as well as an ssh
  39   key to be created for the postgres user.
  40
  41 * Add these to {{{/etc/postgresql/9.6/main/postgresql.conf}}} or equivalent
  42 {{{
  43   track_counts = yes
  44   archive_mode = on
  45   wal_level = archive
  46   max_wal_senders = 3
  47   archive_timeout = 1h
  48   archive_command = '/usr/local/bin/pg-backup-file mXXXXXX-CLUSTERNAMEHERE-XXXXain WAL %p'
  49 }}}
  50
  51 * Run puppet on the postgresql server,
  52
  53 ==== ssh authkeys ====
  54
  55 * If you need extra options in the {{{debbackup-ssh-wrap}}} call on the backup server
  56   (for instance of the host should be allowed to fetch files), manually copy
  57   {{{~postgres/.ssh/id_rsa.pub}}} to
  58   {{{puppet:modules/postgres/templates/backup_server/sshkeys-manual.erb}}}.
  59
  60 ==== base backup config ====
  61
  62 * Run puppet on the backup hosts (storace and backuphost as of 2018).
  63
  64 * On the db server, create a role.  Find the password to use on the backup host in {{{~debbackup/.pgpass}}}:\\
  65   {{{sudo -u postgres createuser -D -E -P -R -S debian-backup}}}
  66 * Give the role replication access:\\
  67   {{{sudo -u postgres psql -c 'ALTER ROLE "debian-backup" REPLICATION;'}}}
  68 * Add an entry to pg_hba to allow access:\\
  69   {{{hostssl replication     debian-backup   5.153.231.12/32                 md5 # backuphost
  70 hostssl replication     debian-backup   2001:41c8:1000:21::21:12/128    md5 # backuphost
  71 hostssl replication     debian-backup   93.94.130.161/32                md5 # storace
  72 hostssl replication     debian-backup   2a02:158:380:280::161/128       md5 # storace}}}
  73 * Ensure pg is listening on *.
  74 * Ensure the server is using ssl and a proper debian auto-ca cert.
  75 * Reload db server.
  76 * Test running "postgres-make-base-backups host:port".
  77 * You should see a tarball and WALs
  78
  79 = Nagios warnings =
  80
  81 == BASE-IS-OLD ==
  82
  83 (2018-02) Our nagios check warns us when a backup server has not successfully fetched
  84 a base backup recently.  The causes often are that either the postgres server or the
  85 backup host went down or was down during the time of the weekly cronjob.
  86
  87 To re-run a base backup for a specific cluster, log into the backup server
  88 (either storace or backuphost), cat /usr/local/bin/postgres-make-base-backups
  89 to see the port for the cluster, and run
  90 {{{
  91   sudo -u debbackup /usr/local/bin/postgres-make-base-backups <host>:<port>
  92 }}}
  93 probably best to do that in a screen as it might take a while.
  94
  95 == MISSING-BASE ==
  96
  97 e.g.:
  98 {{{
  99 sudo -u debbackup /usr/lib/nagios/plugins/dsa-check-backuppg  | grep BASE
 100 [fasolo, dak] MISSING-BASE: dak.BASE.backuphost.debian.org-20180211-012002-fasolo.debian.org-dak-9.6-backup.tar.gz
 101 }}}
 102
 103 This means that we started doing a base backup (as witnessed by a .backup file
 104 next to a WAL), but for some reason we don't have the corresponding base file.
 105 {{{
 106 root@backuphost:/srv/backups/pg/fasolo# ls -l *backup*
 107 -rw------- 1 debbackup debbackup 9201093916 Jan 14 06:18 dak.BASE.backuphost.debian.org-20180114-012001-fasolo.debian.org-dak-9.6-backup.tar.gz
 108 -rw------- 1 debbackup debbackup 9227651542 Jan 21 06:25 dak.BASE.backuphost.debian.org-20180121-012001-fasolo.debian.org-dak-9.6-backup.tar.gz
 109 -rw------- 1 debbackup debbackup 9266306750 Jan 28 07:59 dak.BASE.backuphost.debian.org-20180128-012001-fasolo.debian.org-dak-9.6-backup.tar.gz
 110 -rw------- 1 debbackup debbackup 9312602089 Feb  5 11:00 dak.BASE.backuphost.debian.org-20180204-012001-fasolo.debian.org-dak-9.6-backup.tar.gz
 111 -rw------- 1 debbackup debbackup 9346830509 Feb 12 10:25 dak.BASE.backuphost.debian.org-20180212-094930-fasolo.debian.org-dak-9.6-backup.tar.gz
 112 -rw------- 1 debbackup debbackup        353 Jan 14 06:18 dak.WAL.0000000100000033000000A6.00000028.backup
 113 -rw------- 1 debbackup debbackup        350 Jan 20 11:20 dak.WAL.00000001000000350000008C.00000028.backup
 114 -rw------- 1 debbackup debbackup        353 Jan 21 06:25 dak.WAL.000000010000003600000068.00000028.backup
 115 -rw------- 1 debbackup debbackup        353 Jan 28 07:59 dak.WAL.0000000100000038000000E3.00000028.backup
 116 -rw------- 1 debbackup debbackup        353 Feb  5 11:00 dak.WAL.000000010000003B00000090.00000028.backup
 117 -rw------- 1 debbackup debbackup        350 Feb  5 15:49 dak.WAL.000000010000003B0000009B.00000108.backup
 118 -rw------- 1 debbackup debbackup        353 Feb 11 10:09 dak.WAL.000000010000003D000000AC.00000028.backup
 119 -rw------- 1 debbackup debbackup        353 Feb 12 10:25 dak.WAL.000000010000003E00000027.00000178.backup
 120 }}}
 121
 122 {{{.backup}}} files are created on the postgres server and shipped to the
 123 backup hosts whenever a base backup is initiated.  We do some labelling, so
 124 we know which backup host the corresponding tarball should end up with.
 125
 126 e.g.:
 127 {{{
 128 root@backuphost:/srv/backups/pg/fasolo# cat dak.WAL.000000010000003B00000090.00000028.backup
 129 START WAL LOCATION: 3B/90000028 (file 000000010000003B00000090)
 130 STOP WAL LOCATION: 3B/97CF2138 (file 000000010000003B00000097)
 131 CHECKPOINT LOCATION: 3B/90000098
 132 BACKUP METHOD: streamed
 133 BACKUP FROM: master
 134 START TIME: 2018-02-05 10:25:28 UTC
 135 LABEL: backuphost.debian.org-20180204-012001-fasolo.debian.org-dak-9.6-backup
 136 STOP TIME: 2018-02-05 10:59:50 UTC
 137 }}}
 138
 139 To fix this, verify we have a later base tarball, or that we are fine for some other reason,
 140 and remove the corresponding .backup file.  In the case above, we would remove
 141 {{{dak.WAL.000000010000003D000000AC.00000028.backup}}}.
 142
 143 == WAL-MISSING-AFTER ==
 144
 145 e.g.:
 146 {{{
 147 [bmdb1, main] WAL-MISSING-AFTER: bmdb1/main.WAL.0000000100001340000000DB
 148 }}
 149
 150 If it's just one WAL file missing, it can be recovered from the other backup host.  If more logs are missing, check the server's logs for archive errors.