FreeIPA backup and restore

Why FreeIPA backup and restore needs a planned procedure

A FreeIPA deployment is the identity source for your Linux hosts, Kerberos tickets and issued certificates, so a backup is only useful if you know exactly what it captures and what a restore asks of the rest of your topology. FreeIPA provides ipa-backup to create backups and ipa-restore to bring data back. You choose between a full backup, which captures configuration and data together, and an online data-only backup, which captures directory data while the server keeps running. Each option answers a different recovery question, so decide which one you need before an incident forces the choice.

The backup documentation also sets the most important restore constraint: restoring an outdated backup into an active replica topology can break replication. A backup is a point-in-time copy, and every other server in your deployment has moved on since then. Before you plan a restore, confirm with the project's backup and restore documentation how your chosen restore path expects replicas to be handled, and which server is responsible for certificate renewal and CRL publication, because the documentation notes that the first server handles these by default. Those answers shape which server you back up, where the archives go and what you must rebuild afterward.

Treat the backup procedure as a written, tested runbook rather than a cron job you hope works. Ask your implementation partner or internal team to document which servers hold which roles, where archives are stored and who can access them, and how a restore is verified against replication and certificate services. Confirm the supported restore sequence for your FreeIPA version in your own environment before you rely on it, and record the steps you could not verify so they become known risks. The recovery time you can expect depends on your topology, data volume and storage, so ask for a tested estimate rather than assuming one.

Full backup versus online data-only backup

A full backup is the mode meant to capture a FreeIPA server as a whole. It includes configuration and data, so it is the mode to reach for when you need to rebuild a server's identity state from the backup set. Run it with ipa-backup and the default full mode, and expect the backup to be taken with services stopped, because the directory, Kerberos and certificate data must be consistent with each other at the moment of capture.

Configuration files: server settings that FreeIPA manages, which a restore needs to recreate the same installation.
Directory data: users, groups, hosts, policies and other entries stored in 389 Directory Server.
Kerberos and certificate material: the state the KDC and the Dogtag certificate authority depend on.
Service interruption: plan a maintenance window, since full backups are not the mode for live protection.
Restore target: a full backup is restored onto a matching installation, so record the FreeIPA version with each backup.

Before you rely on any of this, open the official backup documentation for your installed release and confirm exactly which files and components the full mode includes.

Why a server holding every role changes the backup plan

A FreeIPA server can hold several roles at once, and each role keeps state in a different place. The backup plan depends on which roles share a host, because that decides what one backup captures and what a restore must rebuild. Check the role map of every server before choosing between a single role-complete backup and coordinated backups across replicas.

Roles that share one server

A single FreeIPA server can run the 389 Directory Server, the MIT Kerberos KDC, the Dogtag certificate authority, integrated DNS, NTP and the components used for Active Directory trusts. Each role stores data in its own location, so a backup of the host is only useful if it covers every role that host carries. Write down the role list for each server before you schedule anything.

Directory and Kerberos state

The directory holds users, groups, hosts and policies, and the KDC depends on the same data for keys and principals. Restoring one without the other can leave authentication pointing at identities that no longer match. Confirm that your chosen backup type includes the data for both before you rely on it for recovery.

First server and certificate renewal

By default, the first server in a topology handles certificate renewal and CRL publication. If that server is restored from an old backup or lost, renewal and revocation data can fall out of step with the rest of the topology. Identify which server holds this role in your deployment and treat its backup as the most time-sensitive one.

Single role-complete server

Backing up one server that holds every role is simpler to schedule and to explain to auditors, because one job captures the full picture from that host. The cost is that the backup is only as complete as that host's role layout, and a change to where roles live can quietly leave a gap. Re-check the backup scope after every role move or new replica.

Coordinated backups across replicas

Running backups on several replicas gives recovery options if one host is lost, but it creates a risk of mixing data from different points in time. Restoring an outdated backup into a live replica topology can break replication, so the restore sequence must be planned as a set. Agree on backup timing across servers and record which backup belongs to which role.

Dedicated servers and role placement

The deployment recommendations advise dedicated servers without other applications, and they tie PKI and DNS placement to each datacenter. Those rules describe where roles should live, and the backup plan has to follow them. When a role moves to a new host, the backup scope moves with it, so review placement before changing it.

Backup options and when each fits

This table compares the main backup choices for FreeIPA: full versus data-only backups, where the backup runs, where the files are stored and whether runs are scheduled or manual. Read each row for the fit, the restore consequence and what to confirm before you settle on a design.

Option	Fit and restore implication	What to confirm
Full backup	Captures configuration and data together. Restore is the path for rebuilding a server, but restoring an outdated backup into an active replica topology can break replication.	Which restore procedure applies to your FreeIPA version and whether the restored server will be the only live copy.
Online data-only backup	Captures directory data while services keep running. Suits frequent recovery points for user and group data, but it does not replace a full backup for rebuilding a server.	Whether your recovery plan still has a current full backup and how data-only files are restored onto a server with the same version.
Backup run on the first CA server	The first server handles certificate renewal and CRL publication by default, so its state matters most for PKI recovery. Backups here are the natural place to protect CA material.	Which server holds the renewal role in your topology and whether your CA configuration matches the documented default.
Backup run on another replica	Lets you back up without placing load on the CA server, and gives you a copy from a server with a different role. Its data may lag behind the CA server.	Whether this replica holds the CA and DNS roles you need to recover, and how far its data can trail the rest of the topology.
Backup on a server with every role	One run covers DNS, CA and directory roles on the same host. Simplifies inventory but ties backup timing and load to the busiest role.	Whether the vendor documentation supports backing up this role mix in your FreeIPA version, and what the restore order is.
Local storage	Fast to write and simple to set up. Files are lost with the server if it fails, so local copies alone do not protect against losing the host.	How much space each backup type needs on the host and whether a copy is moved off the server before it is needed.
Remote storage	Keeps copies outside the failed host, which matters for multiple server loss. Requires transfer, permissions and retention handling that your team must own.	Access controls on the target, encryption in transit and at rest, and how restores are tested from that location.
Scheduled runs	Give consistent recovery points and a record of when backups completed. Failures can go unnoticed unless alerts are wired to the job.	Who receives failure alerts, how old backups are pruned and whether schedules are coordinated across replicas.
Manual runs	Useful before upgrades, topology changes or maintenance, where you want a known state. Depends on operators remembering to run them and documenting the result.	Which change events require a manual backup in your change process and who records it.

How to run a FreeIPA backup safely

This sequence confirms which server renews certificates, takes a backup of the type you need, checks that the archive is intact, moves a copy outside the failure domain, and leaves a record you can use during a restore.

Map the topology and CA renewal server
Before running anything, list every IPA server, its roles (CA, DNS, NTP, trust controller) and its replication agreements. Identify the server that holds the CA renewal role, since the backup documentation notes that the first server handles certificate renewal and CRL publication by default. Confirm this with the topology tools available in your installed version, such as ipa server-role-find and ipa topologysegment-find. You are done when you have a written list of servers, roles and the CA renewal host, and you know which server you will back up from.
Choose full or data-only backup
Decide between a full backup, which includes system files and configuration, and an online data-only backup, which captures the directory and other data while services keep running. Use a full backup when you need to rebuild a server from scratch or recover system configuration. Use a data-only backup for frequent captures between full runs. Record the choice and the reason, since a restore must match the archive type. Check the options your installed version supports by reading the ipa-backup help output on the host (ipa-backup --help) and the official backup page.
Run ipa-backup on the chosen server
Run ipa-backup as root on the server you selected, using the backup type you chose and any options shown by the help output for your version. Run it on a server that carries every role where possible, so the archive contains the CA and DNS data you may need later. Keep the console output. You are done when the command exits without errors and reports the archive path, typically under the backup directory on the server.
Verify the archive exists and is readable
Confirm the archive file is present in the backup directory, that its size is non-zero, and that its checksum or listing can be read. Compare the file timestamp with the time of the run to confirm you are looking at the new archive, not an older one. Keep the file ownership and permissions as created by the tool, because a restore expects them. You are done when the file lists correctly and the timestamp and size match the run you just performed.
Copy the archive to protected storage
Copy the archive to a storage location outside the failure domain of the IPA servers, such as a separate backup system, a different site or an encrypted object store with restricted access. Treat the archive as sensitive because it contains directory data and key material. Restrict who can read it and log every transfer. Confirm the copy by comparing checksums between the source and the destination. You are done when the checksums match and the copy is stored where the IPA servers cannot overwrite it.
Record the run and confirm retention
Write a backup record that names the source server, its roles, the CA renewal server, the backup type, the archive name, the checksum, the storage location and the operator. Store the record separately from the archive. Confirm your retention rules and how old archives are removed, and tell the team where the restore procedure is kept. You are done when someone else on the team could find the latest archive and its record without asking you.

What a restore requires before you run ipa-restore

The most important restore decision is whether the environment you restore into can safely host the data you are restoring. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so the first check is not the backup file but the topology around it. Before you run ipa-restore, confirm that the FreeIPA and operating system versions on the target server match what the backup documentation requires, and that the backup was taken from a server running the same FreeIPA release. Record the current state of every server in the topology, including which one renews certificates and publishes the CRL, because the first server handles those duties by default and a restore changes what it holds.

Stop the FreeIPA services on the server being restored, and plan how other servers will be kept from replicating stale data into the restored one during the operation. Replication is the mechanism that makes a restore dangerous. A server restored from an older backup carries older entries, older sequence numbers and possibly older certificate state, and once it rejoins, changes can be overwritten or lost in either direction. For that reason, many restores into a live topology end with re-initializing the other replicas from the restored server rather than letting them resume their old agreements. Confirm the re-initialization path with the documentation for your release before you start, and plan who will perform it and in what order.

Before rejoining any other server, verify replication on the restored host. Check that the replication agreements you expect exist and that the directory and CA services report healthy, then run the FreeIPA health check on each server and review the replication status output. Compare user, group and host counts and recent changes against a known-good server so you can see what the backup did not capture. Confirm the certificate authority state and the renewal server role explicitly, since a restore can leave no server holding those duties. If any check fails, stop and resolve it before reconnecting the next replica. Ask your implementation partner or your own team to document these checks in the runbook so they are repeatable on the day they are needed.

Protecting backup archives and access to them

A FreeIPA backup is a copy of the directory, Kerberos and certificate authority state, so it deserves the same protection as the live servers. The cards below cover what the archive holds, how to encrypt and restrict it, and how long copies live and where they are kept.

Treat the archive as sensitive

A FreeIPA backup holds directory data for users, groups, hosts and policies, Kerberos material and Dogtag CA data. Anyone who can read the archive may be able to rebuild identity state or reach key material, so classify it at the same level as the live servers. Confirm the archive contents for your release before you set handling rules, because what is included can change between versions.

Encrypt archives at rest

Encrypt every backup archive before it lands on shared storage, and keep the encryption keys apart from the archives they protect. Store key material in a separate system with its own access controls, such as a dedicated secrets store. Ask your team who can decrypt an archive, how keys rotate, and how you would recover a backup if the key holder is unavailable.

Restrict the backup host

The host that runs ipa-backup, or the storage it writes to, should be a dedicated system with tight administrative access and no unrelated services. Limit login to named administrators, log their sessions, and keep the backup path off general-purpose file shares. Review who holds root on that host as carefully as you review root on the IdM servers themselves.

Set retention by recovery need

Decide how many generations you keep based on how far back you may need to restore, and make sure retention covers the window in which an unnoticed problem could spread through replication. Keep at least one copy that predates the most recent change window. Document the retention schedule, and have someone confirm that old archives are deleted when they age out, including copies on backup media.

Keep off-site copies current

Place at least one copy outside the site or datacenter that hosts the FreeIPA servers, so a site loss does not remove both the servers and their backups. Off-site copies inherit the same encryption and access rules as local ones. Test that an off-site archive can be retrieved and restored into a lab environment, and record who may request its release.

Verify access and copies regularly

Audit who has read access to archives and key material on a fixed schedule, and remove access when people change roles. Check that each backup job finished, that archives are readable, and that copies match what was written. Access reviews and copy checks give you evidence for your audit file and show whether your protections still work.

Questions teams ask before backing up FreeIPA

Can our own team back up and restore FreeIPA without a partner?

Yes, if you have Linux administrators who already run FreeIPA and can read the backup documentation closely. The core tools, ipa-backup and ipa-restore, ship with FreeIPA and support full backups or online data-only backups. The hard part is not the command. It is deciding which backup type each server needs, where copies live, how a restore is sequenced across replicas, and how you prove the restore works. The FreeIPA backup documentation at the project's backup and restore page warns that restoring an outdated backup into an active replica topology can break replication, so a runbook written without that context is a common gap. Teams with few FreeIPA skills usually bring in a partner for the design and first test, then keep the routine work in-house.

Which parts of backup work are one-time and which recur?

One-time work covers designing the procedure for your topology, choosing and securing storage locations, writing the restore runbook and running the first full restore test in an isolated environment. Recurring work covers scheduled backups, monitoring that they completed, periodic test restores, and re-checking the procedure after FreeIPA upgrades or topology changes. Recurring cost is mostly staff time and storage capacity. Ask any provider to split the quote into these two groups so you can see what you keep paying for after the first test.

What makes backup and restore effort larger or smaller?

The main drivers are the number of servers, how many FreeIPA roles run on each one, and how many replicas and data centers form the topology. A server that runs the CA, DNS and trust roles needs more careful handling than a plain replica, because the first server handles certificate renewal and CRL publication by default. Storage choices matter too: on-site, off-site, immutable or encrypted copies each add design and testing steps. Compliance evidence is the last driver. If auditors need retention records, restore logs or dated test results, the procedure must produce them from the start. Confirm each of these in your own environment before requesting a quote.

What do we need to provide during a backup engagement?

Expect to provide read access to the FreeIPA topology, a list of server roles, the storage platforms you already use, and the backup retention rules your organization requires. You will also need a named technical owner who can approve changes, a test environment or spare capacity for restore tests, and staff who can attend change windows. Restore tests usually need a window where replication is paused or the test network is isolated, so agree those windows before work starts. If your policy requires access controls on backup media, confirm who holds the keys and how they are audited.

How often should we schedule test restores?

Schedule a full test restore after the first procedure is designed, then repeat it on a fixed cadence that your risk owner approves, and again after any FreeIPA upgrade, topology change or change to backup storage. The first test shows whether the runbook works. Later tests show whether it still works after the environment has changed. Record the date, the backup used, the servers involved and the replication check results each time, because those records are the evidence most often requested later. Restore tests should run in isolation, never on a live replica topology.

What should a fixed-scope quote for FreeIPA backup include?

Ask for a written scope listing the servers and roles covered, the backup types for each, the storage locations and their security controls, the restore runbook, the test plan and the number of test restores included. Ask which deliverables are one-time and which are recurring, what you must provide, and which change windows are assumed. Request the assumptions in writing, including what happens if the topology is larger than described. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that written scope.

Does DeployOpen issue compliance certificates for our backup controls?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, including backup procedures, restore test records and retention settings. Independent auditors and certification bodies issue audit reports, attestations and certifications. Ask your auditor early which evidence they expect, so the procedure is designed to produce it.

Automating backups with Ansible roles

Wrapping ipa-backup in an Ansible role makes sense when you need the same backup type, schedule and destination on every FreeIPA server, and when those settings must be reviewed like any other infrastructure change. The role should decide which server runs what. Backups are normally taken on one server per topology role, so the inventory needs explicit groups or host variables that separate the server that runs full backups from servers that only need data backups, and it should refuse to run on hosts that are not in the expected group. The role also has to set the storage path, create the directory with restrictive ownership and permissions, keep the output of each run in a log the team can search, and copy backups off the server through a step you control. A role that quietly writes to a path on a host that is about to be rebuilt does not protect anything.

Some work stays outside the role. A successful playbook run only shows that ipa-backup exited cleanly, not that the archive can be restored into a test environment, and it does not show that the replicas still agree with each other. Restore testing and replica checks need their own schedule, a non-production environment, and a named owner who signs off the result. Run ipa-healthcheck or an equivalent replication check as a separate step, and record the outcome next to the backup record. Confirm with your FreeIPA version's Ansible resources which backup options the role exposes, whether it supports online data-only backups, and how it handles retention, before you rely on defaults.

Limits to confirm in your environment

The backup documentation sets the outer limits, but the answers depend on your installed release, your server roles and how DNS and trusts are wired. Treat each item below as a question to settle in a test environment before a backup plan is signed off.

Supported restore path for your release

Confirm which restore procedure applies to the FreeIPA release you run, on the same operating system and package versions as the server that took the backup. Ask whether restores into a fresh host are supported for your topology, and whether the procedure differs for full and data-only backups. Record the exact command sequence your team tested, because the restore steps are the part most likely to need adjustment during an incident.

Online backup coverage by role

Check whether an online data-only backup captures everything your servers do, including certificate authority data, DNS zones and any role-specific configuration. Do not assume that one server's backup represents the whole topology. List every server with a role, then confirm which backup type each one needs. The first server handles certificate renewal and CRL publication by default, so it deserves explicit attention.

Behavior with integrated or external DNS

Find out whether your deployment runs integrated DNS on IdM servers or relies on an external DNS service. Backups of integrated zones and external zone data follow different paths, and a restore can leave records out of step with what clients expect. Confirm how zone data is captured, where it is stored, and how you will verify name resolution after a restore on your own network.

Active Directory trust state

If the deployment has a cross-forest trust with Active Directory, confirm how trust objects, ID ranges and Samba-related configuration are included in backups and how they come back after a restore. Verify that trust relationships work from both sides after recovery. Keep the trust documentation with the backup set, since the IPA domain and AD forest must keep non-overlapping DNS names throughout.

Replica re-initialization after restore

Confirm the exact steps for bringing existing replicas back into agreement after a restore. Restoring an outdated backup into an active replica topology can break replication, so you need a documented decision on whether replicas are re-initialized, rebuilt or left alone. Ask your team to rehearse this on a copy of the topology, since replication errors often appear only after the restored server rejoins.

Retention and testing evidence requirements

Confirm with your compliance owner how long backups must be kept, where they must be stored, who may access them and what evidence of restore testing an assessor expects. FreeIPA provides the backup tooling, but retention periods, encryption requirements and test records come from your own policy and any framework you are assessed against. Ask an assessor or auditor to confirm what they will accept before you design the schedule.

How DeployOpen scopes and delivers FreeIPA backup and restore

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA servers in your cloud accounts, data centers or air-gapped networks. For backup and restore, the work starts with your server roles and recovery requirements, then produces tested backup and restore procedures your own team can run.

How we scope

Inventory every FreeIPA server and the roles each one holds, including CA, DNS and trust roles
Agree which backup types apply: full backups, online data-only backups, or both, with storage locations
Confirm restore requirements, replica re-initialization steps and who approves a restore before work starts
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins

How we build

Configure ipa-backup schedules, retention and off-server storage on infrastructure you control
Build Ansible backup roles that match your server layout, so backups stay consistent across replicas
Test restores in an isolated environment and verify authentication, Kerberos tickets and replication afterwards
Check that the first server's certificate renewal and CRL duties are covered by the backup and restore plan

How we hand over

Deliver written runbooks for full restore, data-only restore and replica re-initialization, with the steps in order
Document backup verification results, including what was restored, what was checked and what remained open
Train your operators to run backups, read their logs and perform a restore drill on their own
Hand over configuration files and roles in your repositories, so your team owns every change after delivery

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Review backup jobs and restore tests after FreeIPA upgrades or server topology changes
Repeat restore drills on a schedule your team agrees, and record the results against the runbook
Ask any provider to confirm response terms, access arrangements and handling of your backup data in writing