Make a base backup

Edit online

Procedure

  1. Download and transfer the base_ackup.sh script to the IBM® Verify Directory container.
    Docker: 
    $> docker cp  base_backup.sh <ivd-container-name>:/var/ivd/data/scripts/base_backup.sh
    Kubernetes: 
    $> kubectl cp base_backup.sh <ivd-pod-name>:/var/ivd/data/scripts/base_backup.sh

    base_backup.sh

  2. Open a shell inside the Verify Directory Server container.
    Docker: 
    $ docker exec -it -u 1000  bash <ivd-container-name> bash
    Kubernetes: 
    $> kubectl exec -it <ivd-pod-name> -- bash
  3. Give the script executable permissions to the base_backup.sh script and run it. 
    $ /var/ivd/data/scripts/base_backup.sh <num_days>

    The script will take a PostrgreSQL cluster Base Backup, and it will DELETE backups older than <num_days> together with all the archived WAL files no longer needed for backups taken less than <num_days> ago. The base_backup.sh script can also be run in no-prompt mode with the -n option, in this mode, all output is generated except for the messages that require user interaction. This flag is optional, and it is perfect to run the script in an automatic or scheduled way.

    This backup method only supports restoration of an entire database cluster, not a subset. The base backup is bulky as it requires a lot of archival storage. To make use of the backup, you will need to keep all the WAL segment files generated during and after the file system backup. Busy systems will generate many megabytes of WAL traffic that have to be archived, which could eventually exceed available disk space. For this reason, it is very important to monitor and do frequent cleanups of old and no longer needed WAL files. To aid you in doing this, the base backup process creates a backup history file, which is named after the first WAL segment file that you need for the file system backup. For example, if the starting WAL file is 0000000100001234000055CD, the backup history file will be named something like 0000000100001234000055CD.007C9330.backup. All archived WAL segments with names numerically less than are no longer needed to recover the file system backup and can safely be deleted. These history files are necessary to allow the system to pick the right WAL segment files when recovering from an archive that contains multiple timelines. Therefore, they are archived into the WAL archive area just like WAL segment files. The history files are just small text files, so it's cheap and appropriate to keep them around indefinitely, unlike the WAL files, which are quite large. The provided base_backup.sh make use of these history files to clean old and no longer needed archived WAL files. It is also advisable to create a mechanism to constantly monitor the file system where the WAL files are being archived. This way, if the file system runs out of space, it can be reported appropriately so that the situation can be resolved reasonably quickly. If the file system containing pg_wal/ fills up, PostgreSQL will do a PANIC shutdown. No committed transactions will be lost, but the database will remain offline until you free some space.If it is not desired to delete backups older than <num_days> and the no longer needed archived WAL files by more recent backups, and just take the Base Backup, then you can do so by running the following command: 
    $ pg_basebackup -U idsldap -d "postgresql://%2Frun%2Fpostgresql/idsldap" -D /var/isvd/data/backups/$(hostname | rev | cut -d '-' -f 3- | rev)_backup_$(date +"%Y-%m-%d-%H:%M") -l Base_Backup_$(date +"%Y-%m-%d-%H:%M") -c spread -F tar -z -P

    It is ideal, with either cron Jobs or Kubernetes jobs, to automate and schedule full backups to be taken daily or, at least, once a week. Since it is not necessary to be concerned about the amount of time it takes to make a base backup, it is recommended to take them with the checkpoint mode set to spread, -c spread, which will make the base backups take longer to complete, but it will hurt performance less. However, if you normally run the server with full_page_writes disabled, you might notice a drop in performance while the backup runs since full_page_writes is effectively enforced during backup mode. Now, if you plan to take the backups at times when the server is less busy, and want to take faster backups, then you can set the checkpoint mode to immediate by modifying the above command to run with the -c fast argument instead.