Chapter 5. Preparing for data loss with IdM backups

IdM provides the ipa-backup utility to backup IdM data, and the ipa-restore utility to restore servers and data from those backups.

This section covers the following topics:

Note

Red Hat recommends running backups as often as necessary on a hidden replica with all server roles installed, especially the Certificate Authority (CA) role if the environment uses the integrated IdM CA. See Installing an IdM hidden replica.

5.1. IdM backup types

With the ipa-backup utility, you can create two types of backups:

Full-server backup
  • Contains all server configuration files related to IdM, and LDAP data in LDAP Data Interchange Format (LDIF) files
  • IdM services must be offline.
  • Suitable for rebuilding an IdM deployment from scratch.
Data-only backup
  • Contains LDAP data in LDIF files and the replication changelog
  • IdM services can be online or offline.
  • Suitable for restoring IdM data to a state in the past

5.2. Naming conventions for IdM backup files

By default, IdM stores backups as .tar archives in subdirectories of the /var/lib/ipa/backup/ directory.

The archives and subdirectories follow these naming conventions:

Full-server backup

An archive named ipa-full.tar in a directory named ipa-full-<YEAR-MM-DD-HH-MM-SS>, with the time specified in GMT time. 

[root@server ~]# ll /var/lib/ipa/backup/ipa-full-2021-01-29-12-11-46
total 3056
-rw-r--r--. 1 root root     158 Jan 29 12:11 header
-rw-r--r--. 1 root root 3121511 Jan 29 12:11 ipa-full.tar
Data-only backup

An archive named ipa-data.tar in a directory named ipa-data-<YEAR-MM-DD-HH-MM-SS>, with the time specified in GMT time. 

[root@server ~]# ll /var/lib/ipa/backup/ipa-data-2021-01-29-12-14-23
total 1072
-rw-r--r--. 1 root root     158 Jan 29 12:14 header
-rw-r--r--. 1 root root 1090388 Jan 29 12:14 ipa-data.tar
Note

Uninstalling an IdM server does not automatically remove any backup files.

5.3. Considerations when creating a backup

The important behaviors and limitations of the ipa-backup command include the following:

  • By default, the ipa-backup utility runs in offline mode, which stops all IdM services. The utility automatically restarts IdM services after the backup is finished.
  • A full-server backup must always run with IdM services offline, but a data-only backup may be performed with services online.
  • By default, the ipa-backup utility creates backups on the file system containing the /var/lib/ipa/backup/ directory. Red Hat recommends creating backups regularly on a file system separate from the production filesystem used by IdM, and archiving the backups to a fixed medium, such as tape or optical storage.
  • Consider performing backups on hidden replicas. IdM services can be shut down on hidden replicas without affecting IdM clients.

  • Starting with RHEL 8.3.0, the ipa-backup utility checks if all of the services used in your IdM cluster, such as a Certificate Authority (CA), Domain Name System (DNS), and Key Recovery Agent (KRA), are installed on the server where you are running the backup. If the server does not have all these services installed, the ipa-backup utility exits with a warning, because backups taken on that host would not be sufficient for a full cluster restoration.

    For example, if your IdM deployment uses an integrated Certificate Authority (CA), a backup run on a non-CA replica will not capture CA data. Red Hat recommends verifying that the replica where you perform an ipa-backup has all of the IdM services used in the cluster installed.

    You can bypass the IdM server role check with the ipa-backup --disable-role-check command, but the resulting backup will not contain all the data necessary to restore IdM fully.

5.4. Creating an IdM backup

Follow this procedure to create a full-server and data-only backup in offline and online modes using the ipa-backup command.

Prerequisites

  • You must have root privileges to run the ipa-backup utility.

Procedure

  • To create a full-server backup in offline mode, use the ipa-backup utility without additional options. 

    [root@server ~]# ipa-backup
Preparing backup on server.example.com
Stopping IPA services
Backing up ipaca in EXAMPLE-COM to LDIF
Backing up userRoot in EXAMPLE-COM to LDIF
Backing up EXAMPLE-COM
Backing up files
Starting IPA service
Backed up to /var/lib/ipa/backup/ipa-full-2020-01-14-11-26-06
The ipa-backup command was successful

  • To create an offline data-only backup, specify the --data option. 

    [root@server ~]# ipa-backup --data

  • To create a full-server backup that includes IdM log files, use the --logs option. 

    [root@server ~]# ipa-backup --logs

  • To create a data-only backup while IdM services are running, specify both --data and --online options. 

    [root@server ~]# ipa-backup --data --online
Note

If the backup fails due to insufficient space in the /tmp directory, use the TMPDIR environment variable to change the destination for temporary files created by the backup process: 

[root@server ~]# TMPDIR=/new/location ipa-backup

For more details, see ipa-backup Command Fails to Finish.

Verification Steps

  • The backup directory contains an archive with the backup. 

    [root@server ~]# ls /var/lib/ipa/backup/ipa-full-2020-01-14-11-26-06
header  ipa-full.tar

5.5. Creating a GPG2-encrypted IdM backup

You can create encrypted backups using GNU Privacy Guard (GPG) encryption. The following procedure creates an IdM backup and encrypts it using a GPG2 key.

Prerequisites

Procedure

  • Create a GPG-encrypted backup by specifying the --gpg option. 

    [root@server ~]# ipa-backup --gpg
Preparing backup on server.example.com
Stopping IPA services
Backing up ipaca in EXAMPLE-COM to LDIF
Backing up userRoot in EXAMPLE-COM to LDIF
Backing up EXAMPLE-COM
Backing up files
Starting IPA service
Encrypting /var/lib/ipa/backup/ipa-full-2020-01-13-14-38-00/ipa-full.tar
Backed up to /var/lib/ipa/backup/ipa-full-2020-01-13-14-38-00
The ipa-backup command was successful

Verification Steps

  • Ensure that the backup directory contains an encrypted archive with a .gpg file extension. 

    [root@server ~]# ls /var/lib/ipa/backup/ipa-full-2020-01-13-14-38-00
header  ipa-full.tar.gpg

Additional resources

5.6. Creating a GPG2 key

The following procedure describes how to generate a GPG2 key to use with encryption utilities.

Prerequisites

  • You need root privileges.

Procedure

  1. Install and configure the pinentry utility. 

    [root@server ~]# yum install pinentry
[root@server ~]# mkdir ~/.gnupg -m 700
[root@server ~]# echo "pinentry-program /usr/bin/pinentry-curses" >> ~/.gnupg/gpg-agent.conf

  2. Create a key-input file used for generating a GPG keypair with your preferred details. For example: 

    [root@server ~]# cat >key-input <<EOF
%echo Generating a standard key
Key-Type: RSA
Key-Length: 2048
Name-Real: GPG User
Name-Comment: first key
Name-Email: root@example.com
Expire-Date: 0
%commit
%echo Finished creating standard key
EOF

  3. (Optional) By default, GPG2 stores its keyring in the ~/.gnupg file. To use a custom keyring location, set the GNUPGHOME environment variable to a directory that is only accessible by root. 

    [root@server ~]# export GNUPGHOME=/root/backup

[root@server ~]# mkdir -p $GNUPGHOME -m 700

  4. Generate a new GPG2 key based on the contents of the key-input file. 

    [root@server ~]# gpg2 --batch --gen-key key-input

  5. Enter a passphrase to protect the GPG2 key. You use this passphrase to access the private key for decryption. 

    ┌──────────────────────────────────────────────────────┐
│ Please enter the passphrase to                       │
│ protect your new key                                 │
│                                                      │
│ Passphrase: <passphrase>                             │
│                                                      │
│	 <OK>                             <Cancel>         │
└──────────────────────────────────────────────────────┘

  6. Confirm the correct passphrase by entering it again. 

    ┌──────────────────────────────────────────────────────┐
│ Please re-enter this passphrase                      │
│                                                      │
│ Passphrase: <passphrase>                             │
│                                                      │
│	 <OK>                             <Cancel>         │
└──────────────────────────────────────────────────────┘

  7. Verify that the new GPG2 key was created successfully. 

    gpg: keybox '/root/backup/pubring.kbx' created
gpg: Generating a standard key
gpg: /root/backup/trustdb.gpg: trustdb created
gpg: key BF28FFA302EF4557 marked as ultimately trusted
gpg: directory '/root/backup/openpgp-revocs.d' created
gpg: revocation certificate stored as '/root/backup/openpgp-revocs.d/8F6FCF10C80359D5A05AED67BF28FFA302EF4557.rev'
gpg: Finished creating standard key

Verification Steps

  • List the GPG keys on the server. 

    [root@server ~]# gpg2 --list-secret-keys
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/root/backup/pubring.kbx
------------------------
sec   rsa2048 2020-01-13 [SCEA]
      8F6FCF10C80359D5A05AED67BF28FFA302EF4557
uid           [ultimate] GPG User (first key) <root@example.com>

Additional resources