Restore online backup on a different server

Edit online

Procedure

  1. Stop the database 
    $ /usr/pgsql-14/bin/pg_ctl stop -D /var/isvd/data/db
    Note:

    Ensure that the target uses the same WAL archiving configuration as the source database, as described in the Configure WAL archiving.

  2. Make a copy of the entire cluster data directory on the target server.
    If space permits, copy the entire cluster data directory and any tablespaces to keep a backup of the current state. 
    $ cd /var/isvd/data/
$ cp -rp db/* db_copy
  3. Synchronize crypto and schema files if the servers are not already in sync.
    Note: If the source and target servers do not have the same data, the same key‑stash file, and the same schema files, perform the following steps or skip to step 4.
    1. Crypto synchronization
      • Copy the ibmslapddir.ksf file from the source IBM® Verify Directory container.
        Note: This step can be skipped if the instances are already crypto‑sync’d.
      • To check if the servers are crypto synchronized, run the following command on both the source and target servers and compare the results. 
        base64 /var/isvd/data/db/ibmslapddir.ksf
      • If the servers are not crypto‑sync’d, copy the ibmslapddir.ksf file as follows.
        • Docker 
          $ docker cp <ivd-source-container-name>:idsslapd-idsldap/etc/ibmslapddir.ksf ibmslapddir.ksf
        • Kubernetes 
           $> kubectl cp <ivd-source-pod-name>:idsslapd-idsldap/etc/ibmslapddir.ksf ibmslapddir.ksf
    2. Schema synchronization
      • Copy all the V3.* schema files from the source Verify Directory Server container.
        Note: This step can be skipped if the servers are already schema-sync'd.*
      • To check if the schema files are in sync, run the following commands in the persistent volume claim (PVC) mount path directory, for example, /var/isvd/data on both servers and compare the results.
        • cd /var/isvd/data/
        • ls -l schema/V3*
        • cksum schema/V3*
      • If the servers are not schema‑sync’d, copy all the V3.* schema files as follows.
        • Docker 
          $> docker cp <ivd-source-container-name>:/var/ivd/data/schema schema
        • Kubernetes 
          $> kubectl cp <ivd-source-pod-name>:/var/ivd/data/schema schema
    3. Copying files to the target server
      • Copy the ibmslapddir.ksf file to the target IBM Verify Directory container.
        • Docker 
          $> docker cp ibmslapddir.ksf <ivd-target-container-name>:/var/ivd/data/db/
        • Kubernetes 
          $> kubectl cp ibmslapddir.ksf <ivd-target-pod-name>:/var/ivd/data/db/
      • Copy all the V3.* schema files to the target Verify Directory Server container.
        • Docker 
          $> docker cp schema <ivd-target-container-name>:/var/ivd/data/db/
        • Kubernetes 
          $> kubectl cp schema/ <ivd-target-pod-name>:/var/ivd/data/db/
  4. Transfer every needed backed‑up file from the source server to the target server and restore the database.
    1. First, save the contents of the cluster’s pg_wal subdirectory, as it might contain logs that were not archived before the system went down. 
      $ cp -rp db/pg_wal/ backups/pg_wal_restore_$(hostname | rev | cut -d '-' -f 3- | rev)_$(date +"%Y-%m-%d-%H:%M")
    2. Then transfer the backup directory from the source server to the target server.
    3. The backup directory must contain the <pg_wal_restore_...> directory with all the unarchived WAL segment files saved in the previous step, the base backup to be restored, and the archivedir directory.
    4. Lastly, restore the database by following steps 4-8 of the Restore from a continuous archive backup (Online backup)

      For more information, see PostgreSQL continuous archiving