alvierahman90/notes
1
1
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
5d412184a8
notes/postgres.md
Alvie Rahman 3108805fbb initial commit
2021-07-04 12:18:08 +01:00

4.7 KiB
Executable File
Raw Blame History

author date title
Alvie Rahman \today postgres notes

\tableofcontents

Chapter 24: Backup and Restore1

Three types of backups:

  • SQL dump---create text file of SQL commands that can recreate the database

    pg_dump dbname > outfile

    To restore: psql dbname < infile

    • must be run as database superuser
    • can be run remotely
    • set host and username with -h and -U switches

  • File system level backup

    tar -cf backup.tar /usr/local/pgsql/data

    • The database server must be shut down
    • You can only backup and restore entire database clusters

  • Continuous archiving (write ahead log archiving)

    • "We do not need a perfectly consistent file system backup as the starting point."

    • method can be used to create a continuous backup

    • supports point in time recovery

    • can be used to create a warm standby system

    • can only be used to restore an entire database cluster

    • requires a lot of archival storage

SQL Dump

Restoring a dump

Important note before you restore a database:

Before restoring an SQL dump, all the users who own objects or were granted permissions on objects in the dumped database must already exist. If they do not, the restore will fail to recreate the objects with the original ownership and/or permissions. (Sometimes this is what you want, but usually it is not.)

You should probably read the whole document here

File system backup

You can run a FS level backup with minimal downtime with rsync:

  1. Perform a backup with rsync while system is live
  2. Shut down database server
  3. Rerun rsync backup command
  4. Restart database server

The second rsync command will run significantly quicker as it only has to transfer what has changed since the first backup.

Write Ahead Log (WAL) archiving

  • WAL segment files usually get "recycled" by being renamed

  • to archive WAL data, the content of each segment is captured and saved before it is reused

    • you can save the data any way you like

  • to enable WAL archiving:

    1. set wal_level to archive (or hot_standby)

    2. set archive_mode to on

    3. set archive_command to the command to use to backup

      • e.g.

        archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'  # Unix
archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows

        where %f is the filename of the file to archive and %p is the path of file to archive:

        test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

      • The command must only ever return a exit status of 0 *only if it succeeds

        • postgres will recycle the file if the command returns 0

      • The archived data should have minimal access permissions

      • the archive command should generally refuse to overwrite files and return non-zero

      • In writing your archive command, you should assume that the file names to be archived can be up to 64 characters long and can contain any combination of ASCII letters, digits, and dots.

      • It is not necessary to preserve the original relative path (%p) but it is necessary to preserve the file name (%f).

    4. make a base backup

make a base backup

  1. ensure WAL archiving is enabled and working

  2. issue the following command as superuser:

    SELECT pg_start_backup('label');
    • label is any string to uniquely identify backup operation, e.g. the full path where you intend to put the backup dump file
    • It does not matter which database within the cluster you connect to to issue this command

  3. Perform the backup, using any convenient file-system-backup tool such as tar or cpio (not pg_dump or pg_dumpall). It is neither necessary nor desirable to stop normal operation of the database while you do this.

  4. issue the following command as superuser:

    SELECT pg_stop_backup();

    this terminates the backup mode and performs an automatic switch to the next WAL segment

You can also use the pg_basebackup tool to take the backup, instead of manually copying the files. This tool will do the equivalent of pg_start_backup(), copy and pg_stop_backup() steps automatically, and transfers the backup over a regular PostgreSQL connection using the replication protocol, instead of requiring file system level access. pg_basebackup does not interfere with file system level backups taken using pg_start_backup()/pg_stop_backup().