End of Sale Notice:

F5 NGINX is announcing the End of Sale (EoS) for NGINX Controller API Management Module, effective January 1, 2024.

F5 maintains generous lifecycle policies that allow customers to continue support and receive product updates. Existing NGINX Controller API- Management customers can continue to use the product past the EoS date. License renewals are not available after September 30, 2024.

See our End of Sale announcement for more details.
End of Sale Notice:

F5 NGINX is announcing the End of Sale (EoS) for NGINX Controller Application Delivery Module, effective January 1, 2024.

F5 maintains generous lifecycle policies that allow customers to continue support and receive product updates. Existing NGINX Controller Application Delivery customers can continue to use the product past the EoS date. License renewals are not available after September 30, 2024.

See our End of Sale announcement for more details.

Back Up & Restore an Embedded Config Database

Learn how to back up and restore the embedded NGINX Controller config database.

Overview

Follow the steps in this guide to back up and restore an internal NGINX Controller config database. Use this guide if you selected the option to use an embedded config database when you installed NGINX Controller. Embedded config means that NGINX Controller is using an internal database to store configuration data.

Automated Backups of Embedded Config Database

NGINX Controller automatically takes a snapshot of the embedded config database every 60 minutes and saves the backups on the config DB volume. The backup file location varies depending on the volume chosen at setup:

  • Local: The backup files are located in /opt/nginx-controller/postgres_data/ with the following naming scheme: backup_<timestamp>.tar.

  • NFS: The backup files are located in the path on the NFS server host that was specified during installation and have the following naming scheme: backup_<timestamp>.tar.

These automated config backups do not include backups of metrics data, which must be backed up separately; refer to Backup & Restore the Metrics Database for those instructions.

Tip:
As a best practice, we recommend that you make scheduled backups of the entire config DB volume and keep the backups off-site for safekeeping.

 


Restore Embedded Config Database

This section explains how to restore the embedded config database from the latest backup file or a specific, timestamped file.

Important:
If you restore the config database on top of a new installation of NGINX Controller, make sure to follow the steps to restore your NGINX config and encryption keys afterward.
  • To restore the embedded NGINX Controller config database from the latest automated backup, run the following command:

    /opt/nginx-controller/helper.sh backup restore
    
  • To restore the embedded config database from a specific backup file:

    /opt/nginx-controller/helper.sh backup restore <filename>
    
    • If you installed the embedded config database on a local volume, the backup files are located in /opt/nginx-controller/postgres_data/.

    • If you installed the embedded config database on an NFS volume, follow the steps in (NFS) Copy Config Database Backup to Local Volume for Restoration to download the backup file to your local volume, and then use the helper.sh script to restore from it.

 

(NFS) Copy Config Database Backup to Local Volume for Restoration

To restore the embedded config database from a specific backup file, the file needs to be on your local volume.

Take the following steps to copy an embedded config database backup file from an NFS volume to your local volume for restoration:

  1. Log on to the node where PostgreSQL is installed as a user with sudo privileges.

  2. Change to the /opt/nginx-controller directory:

    cd /opt/nginx-controller
    
  3. Create a local backup directory to copy the backup file to:

    mkdir local_backups
    
  4. Get the NFS volume details:

    mount | grep nfs
    

    The output looks similar to the following:

    <nfs_host>:<path_on_host> on <local path> type nfs4 (mount options...)
    

    For example:

    192.0.2.1:/mnt/nfs_share/nfs_postgresql on /var/lib/kubelet/pods/1ce4e221-d6d6-434f-9e73-bc81c879530e/volumes/kubernetes.io~nfs/controller-postgres type nfs4 (mount options ...)
    
  5. Record the <nfs_host>:<path_on_host> details corresponding to the nfs_postgresql volume, namely the volume mounted on the Kubernetes controller-postgres container.

    For example:

    192.0.2.1:/mnt/nfs_share/nfs_postgresql
    
  6. Create a parent directory to mount the NFS path to:

    sudo mkdir -p /mnt/local_pgdata
    
  7. Mount the NFS path:

    sudo mount <nfs_host>:<path_on_host> /mnt/local_pgdata
    

    For example:

    sudo mount 192.0.2.1:/mnt/nfs_share/nfs_postgresql /mnt/local_pgdata
    
  8. View the list of the available backup files. The files have the following naming scheme: backup_<timestamp>.tar.

    ls /mnt/local_pgdata/
    
  9. Copy the backup file from which you want to restore to the local_backups/ directory:

    sudo cp /mnt/local_pgdata/backup_<timestamp>.tar local_backups/
    
  10. Use the NGINX Controller helper.sh script to restore the backup file:

    /opt/nginx-controller/helper.sh backup restore local_backups/backup_<timestamp>.tar
    
  11. After the backup has been restored, you can unmount the NFS path and delete the backup file in the local_backups directory:

    sudo umount /mnt/local_pgdata
    rm -i local_backups/backup_<timestamp>.tar
    

 


What’s Next