FreeIPA disaster recovery with VM snapshots

When FreeIPA disaster recovery with VM snapshots is the right path

A hypervisor snapshot can be a valid FreeIPA recovery source, but only in some scenarios, so decide before you roll anything back. The first question is what the snapshot captured. A VM snapshot records the disk and memory state of one guest at one moment, including the 389 Directory Server database, Kerberos keys and Dogtag CA data stored on that server. An ipa-backup archive is a FreeIPA-aware export that the product creates and can restore with its own tooling. The two are not interchangeable, and the vendor documentation does not describe what a snapshot of a running, replicated server guarantees about directory or CA consistency. Confirm with your hypervisor vendor how it quiesces guests and whether application-level consistency is provided, and do not assume it.

Multi-master replication changes the picture. Each FreeIPA server holds a writable copy of the directory, so a snapshot from one replica reflects that replica's state at one time, not the whole topology. Restoring it into a deployment where other replicas kept accepting changes can leave the topology inconsistent. The first server also has a special role: by default it handles certificate renewal and CRL publication, so the CA state on that host is the one you must examine closely. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Your choice therefore depends on whether all servers are lost, whether some survive and still work, or whether you are rebuilding in a new environment.

Treat the scenario as the decision. If every server is gone and you hold only snapshots, plan a restore from those images and then verify directory, Kerberos, CA and replication health before any client depends on them. If some replicas still run correctly, a snapshot of a failed server is usually a poor source for the live topology, and you should consider re-initializing from a healthy replica instead. If you are moving to new hosts, a documented migration path such as ipa-migrate may fit better than a disk image. Before the incident, record which server holds the CA renewal role, confirm your snapshot schedule covers every replica, and agree the verification steps with the people who own the CA and DNS.

Which recovery scenario fits your FreeIPA deployment

This table compares three snapshot-based recovery scenarios for FreeIPA: all servers lost, some replicas still working, and a new environment. Read each row against your own topology, then confirm the first check before changing anything in production. The main takeaway is that the scenario you are in determines whether snapshots restore service directly or serve only as a source for rebuilding replicas.

Scenario	When it fits	What must be true before starting	Main risk	First check to run
Snapshot-only recovery (all servers lost)	Every FreeIPA server and its replicas are gone or unusable, and you hold VM snapshots taken from the full topology.	Snapshots are complete for every server, were taken at a known point in time, and are readable outside the failed hypervisor or storage.	Restoring a snapshot older than the latest changes loses directory data and certificate state written after that point.	Confirm which snapshot is the newest consistent set for all servers and that each one boots with its FreeIPA services stopped.
Partially working topology (some replicas survive)	One or more replicas still answer LDAP and Kerberos, and the lost servers can be rebuilt from them.	Surviving replicas are healthy, the failed servers are removed from agreements, and you know which server renews certificates.	Restoring an outdated snapshot into an active replica topology can break replication, as FreeIPA's backup documentation warns.	List replication agreements and topology status from a surviving server before restoring or re-adding anything.
New environment restore	The original hosts or network cannot be reused, and you rebuild FreeIPA on new infrastructure from backup or snapshot data.	New hostnames, IP addresses and DNS names are planned, and the restore source matches the FreeIPA version you will install.	Client enrollments, DNS records and certificates still point to the old realm or servers, so services fail after cutover.	Verify the restored data loads on an isolated server and that the realm, domain and server names match what clients expect.

Recovering a FreeIPA topology from snapshots only

This sequence restores every FreeIPA server from a single point-in-time set of VM snapshots, brings them back in a controlled order, and confirms that directory, Kerberos, CA and DNS services work before any client is allowed to reconnect. It is meant for cases where no usable ipa-backup exists or the backup is older than the snapshots.

Confirm snapshot age and coverage
Before touching any host, the recovery lead lists every FreeIPA server in the topology and checks that each one has a snapshot taken from the same known point in time. Record the snapshot timestamp for each server, note which servers hold the CA and DNS roles, and identify any server missing from the set. Confirm with the team that changes made after that timestamp, such as new users, host enrollments or certificate renewals, will be lost or must be re-applied. The step is done when a written inventory lists every server, its snapshot time and its roles, and the team has accepted the data gap.
Isolate restored hosts from the network
Attach each restored virtual machine to an isolated network segment or disable its network interfaces before first boot. This prevents a snapshot copy from contacting live replicas, clients or DNS forwarders, which can cause conflicting replication or certificate state. Confirm the hypervisor settings for each VM, including any cloned MAC addresses or duplicate hostnames that a snapshot may carry. The step is done when every restored VM is confirmed to have no route to production networks and the isolation settings are recorded.
Boot the first server and verify its services
Start the server that held the CA renewal and CRL publication role first. By default, that is the first server in the topology, so the recovery lead should confirm which host that is from the inventory. Once it is up, check the 389 Directory Server, the MIT Kerberos KDC, the Dogtag CA and the DNS service if the server runs it. Review the FreeIPA and system logs for replication or certificate errors. The step is done when the directory answers queries, a Kerberos ticket can be obtained for an administrator, the CA reports its status as running, and no fatal errors appear in the logs.
Boot remaining replicas in planned order
Start the other replicas one at a time, in the order set by the recovery plan, typically the replicas that already hold CA or DNS roles before those that hold only directory data. After each boot, confirm that the replica rejoins the topology and that replication agreements show no errors. Do not start several replicas at once, because they may all attempt to resolve the same stale state. The step is done when every replica has been started in sequence and each one reports healthy replication to at least one peer.
Check replication and topology consistency
From a server with a valid admin ticket, review the replication topology and agreements for every server. Confirm that each server sees the same set of replicas and that no agreement points to a host that was removed or rebuilt. Compare recent entries, such as a test user created before the snapshot, across at least two servers to confirm the data matches. Note any server whose data is older than the others. The step is done when all expected replicas appear in the topology, replication reports no errors, and a spot check returns identical records on each server.
Verify CA, certificate renewal and CRL state
Confirm that the CA is running and that the renewal master role points to the intended server. Check the certificate tracking status for critical service certificates and confirm the CRL is published from the expected host. If the snapshot is older than some certificate renewals, some certificates may be on the wrong side of a renewal boundary, so review expiry dates and plan renewals before clients depend on them. The step is done when the renewal role is confirmed, tracked certificates show their expected status, and the CRL publication location is documented.
Re-enable networking and reconnect clients
Restore network access for the FreeIPA servers in stages, starting with DNS and the directory, then Kerberos and the CA. Verify that DNS resolution of the IPA domain and service records works from a test client before allowing production hosts to rejoin. Let clients reconnect in small groups and watch for failed logins or stale keytabs. Use the ipa-healthcheck output and the FreeIPA logs to confirm stability over the first hours. The step is done when a test client authenticates successfully, DNS SRV records resolve, and the group of reconnecting clients shows no new authentication failures.

What a VM snapshot cannot protect you from

A snapshot restores a point in time, not a correct directory. The five risks below come from how FreeIPA stores data, replicates changes, renews certificates and depends on storage, so each one needs a check before you trust a restored server.

Snapshots older than recent changes

A snapshot taken before the latest users, groups, host enrollments or policy edits brings back the old state, and any account created after that point disappears. Compare the restored user and host lists against your change records and the last known good export. Confirm which changes made after the snapshot time must be reapplied by hand, and record that list before you bring the server into service.

Replicas diverging from an outdated restore

A restored server with older data can start serving that state to replicas that never went down, and the topology can end up with two different views of the same objects. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Before reconnecting, list the replication agreements on every surviving server and decide which copy is authoritative.

Snapshots that already hold the damage

A snapshot taken after corruption or a bad bulk change preserves the broken data exactly as it was. Restoring it reproduces the fault rather than removing it. Look for snapshots from before the first symptom, and verify each candidate by reading the directory and running the health check on a cloned copy before you use it for recovery.

Stale certificates and CRLs after restore

Certificate renewal and CRL publication run on the first CA server by default, so a snapshot can carry certificates, expiry dates and revocation lists from a different moment than the current deployment. Check which server holds the renewal role, compare certificate expiry dates with the current date, and confirm the CRL publishes correctly before clients rely on it.

Snapshots on failing storage

Snapshots stored on the same datastore as the failing disks, or in the same hypervisor cluster, can be lost or damaged with the originals. Confirm where each snapshot copy is kept, whether it lives on separate storage and hosts, and whether you have restored one from that location in a test. Ask your hypervisor team to demonstrate the copy before you depend on it.

Restoring into a new environment and moving the data

Rebuilding in a new environment is safer than reviving old VMs when you cannot establish which copy of the directory is authoritative, when the old hosts share a compromised hypervisor, storage or credential path, or when the snapshots sit in a topology whose replication state you cannot verify. In those cases, a new FreeIPA deployment built from current, patched hosts avoids carrying forward corrupted data or attacker changes. The decision depends on what is still trustworthy in the old environment: if you have a snapshot set you can date and validate, a snapshot restore is faster; if you do not, a fresh build with data moved across is the more defensible path. Confirm with your security and identity owners which of these holds before you choose.

The ipa-migrate tool moves users, groups, certificates, sudo and HBAC rules, hosts, services, DNS, OTP tokens and policies between two FreeIPA deployments over LDAP, according to the FreeIPA to FreeIPA migration design page, so it can carry most of the identity data out of a damaged source. Treat it as a data transfer, not a replica repair: the target must be built, tested with real clients and realm settings, and its own replication and CA roles verified before any cutover. Plan the cutover window, the client re-pointing and a rollback path, and confirm with the design page and the release you run which objects and attributes your version migrates, since migration scope and Kerberos handling must be checked against your source data.

Checking replication after a FreeIPA snapshot restore

When every server in the topology was restored from the same snapshot point, all replicas should come back holding the same data. The check is less about finding divergence and more about confirming that the restored servers still agree with each other and with the topology you planned. Start by comparing the replica list against your reference design. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica, so a restored topology that exceeds those limits needs review before it is trusted.

Replication agreements: List agreements from each server and confirm every expected link exists, with no leftover entries for servers that were removed or lost.
Directory data: Compare user, group, host and policy counts across replicas, and spot-check a sample of recently changed entries.
DNS and CA services: Run name resolution against each DNS server and confirm the CA renewal role is still assigned to the server you expect.
Client logins: Sample Kerberos logins from clients enrolled in different sites, using accounts created shortly before the snapshot.
Replication status: Check that replication runs without errors on every agreement before you reopen the environment to users.

Confirm the restored topology matches the reference design and that replication reports clean status on every agreement.

Protecting snapshots that hold identity and key material

A FreeIPA VM snapshot contains the directory, Kerberos keys, CA material and DNS data for the whole identity domain, so it deserves more protection than most backups. The cards below cover who can reach snapshot stores, how they are encrypted and retired, and what to verify before a restored image goes back on the network.

Restrict access to snapshot stores

Anyone who can read a FreeIPA server image can read its directory database, its Kerberos master key material and its Dogtag CA keys, so snapshot stores are as sensitive as the live servers. Limit read access to a small named group of platform and security administrators, separate hypervisor administration from snapshot storage access where your environment allows it, and log every export, clone and mount. Confirm who can attach a snapshot disk to a running VM, since that is an easy path to a copy of live identity data.

Encrypt snapshots at rest

Snapshot files are full disk images, so they hold everything the server held in plaintext on its disks. Use encryption at rest on the storage backend that holds snapshots and exported images, and keep the key management separate from the storage administrators. Ask your hypervisor and storage vendors to confirm how snapshot chains and replicated copies are encrypted, because a snapshot may be copied to a second site through a path that is not encrypted by default.

Set retention and deletion rules

Old snapshots keep old secrets, revoked accounts and superseded certificates alive in a recoverable form. Define how long each FreeIPA snapshot is kept, how many generations are retained per server, and who approves deletion. Deletion should remove every copy, including replicas in other sites and backup targets, and should be recorded. Keep the snapshot schedule aligned with the replication and backup plan so that no retained image is older than the point you would accept losing.

Treat restored images as sensitive

A restored VM image is a new copy of the identity system, not a neutral test artifact. Before booting it, disconnect it from production networks, change the hostname and IP addresses in a controlled way, and make sure it cannot accept client traffic or act as a replication peer until it has been checked. Keep test clones from snapshots in the same access tier as the originals, and destroy them when the exercise ends.

Check patch level before restoring

A snapshot captures the FreeIPA release installed on the day it was taken. FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Before restoring, confirm which FreeIPA release and operating system patch level the snapshot brings back, and whether it still needs those fixes. If it does, apply them to the restored server before it rejoins the topology.

Questions buyers ask before hiring help with FreeIPA recovery

What drives the cost and effort of a FreeIPA snapshot recovery?

The main driver is how many FreeIPA servers were lost or damaged and how many clean snapshots survive. A snapshot-only recovery where every server can be restored from one consistent point is usually less work than a partially working topology, where surviving replicas must be checked against restored data and reconciled. Other factors include the number of replicas and CA servers, whether DNS and the certificate authority run on the affected hosts, how many clients depend on the realm, and whether the hypervisor's snapshot process is well documented. Costs have two parts: the assessment and recovery work itself, and any follow-up testing, runbook writing or hardening you commission afterwards. Ask any provider for a quote that lists each scenario it covers, the hosts in scope and the verification steps included.

How long does a FreeIPA recovery from VM snapshots take?

No general duration can be stated responsibly, because it depends on the scenario, the size of the directory, the number of servers and how quickly your team can grant access and approve changes. The factors that stretch the work are missing or unverified snapshots, unclear change records that make the correct restore point hard to choose, replicas that have diverged, certificate and DNS state that must be checked by hand, and the number of client machines that need re-validation afterwards. Build time into the plan for the verification pass after restore, not only the restore itself. Ask for a timeline that separates assessment, restore, replication checks and client tests so you can see where time is spent.

What must our team provide before recovery work starts?

Three things make the work faster and safer. First, hypervisor access with enough rights to list, clone and revert snapshots on the FreeIPA VMs, plus console access to each guest. Second, a snapshot inventory: for each VM, the snapshot names, creation times, the state of the guest when each was taken, and whether memory state was included. Third, change records for the FreeIPA topology: when replicas were added or removed, recent certificate renewals, DNS changes, password policy edits and any restores already attempted. Also provide the most recent ipa-backup files if they exist, the list of replicas and CA renewal server, and the name of a person who can approve changes during the work.

Can an internal team run a FreeIPA snapshot recovery on its own?

Yes, a team with FreeIPA administration experience and hypervisor skills can attempt it, and many do. The gaps tend to appear in replication topology decisions, certificate authority state and the order of operations after a restore, where a mistake can break replication across servers. Ask yourself whether at least one person has restored FreeIPA before, has rehearsed the procedure in a non-production copy, and can read replication and certificate status output confidently. If not, a fixed-scope engagement can cover the assessment and recovery while your team learns the steps. DeployOpen plans, implements, backs up and documents self-hosted open-source platforms inside your own infrastructure, so the work stays in your environment.

How do we tell which recovery scenario applies to our FreeIPA deployment?

Start by listing which servers still answer, which hold the CA renewal role and which contain the most recent data. A snapshot-only scenario means every FreeIPA server has been lost or corrupted and only VM snapshots remain. A partially working scenario means some replicas still serve authentication and can be compared with restored copies before any change is made. A new-environment scenario means you rebuild the realm on new hosts and bring data across. Confirm the state of certificate renewal and CRL publication on the first server, since FreeIPA's backup documentation notes that the first server handles these by default. Restoring an outdated backup into an active replica topology can break replication, so do not decide the scenario by guesswork. Treat this classification as the first deliverable of any assessment.

What should we confirm with the hypervisor vendor about snapshot consistency?

Ask whether snapshots of running guests are crash-consistent or application-consistent, and whether the hypervisor quiesces the guest filesystem before taking one. Confirm whether memory state is included and how reverting a snapshot behaves for a VM that has been running for a long time. Ask how snapshot chains affect disk performance and how long they may be kept before consolidation. Check whether cloning a snapshot to a new host produces duplicate identifiers or network settings that FreeIPA would see as a conflicting server. Get the answers in writing and test them on a copy. These are questions for your hypervisor vendor and your own environment, not for FreeIPA documentation alone.

Does a recovered FreeIPA deployment need replication checks afterwards?

Yes. Once servers are back, check replication agreements between every pair of replicas, confirm that the directory data matches across servers, and verify that Kerberos authentication, DNS resolution and certificate services work from both a server and a client. The FreeIPA deployment recommendations advise two to three replicas in each datacenter, no more than four replication agreements per replica, and at least one replica per datacenter running the certificate authority or DNS when those roles are used. Compare your restored topology against that guidance and document any deviation. Ask for these checks to be written as a runbook you can repeat.

Limits to confirm in your environment before you rely on snapshots

A VM snapshot is only a recovery point if the hypervisor, the FreeIPA version and the topology behind it all behave as you expect. The cards below cover the items to verify with your own environment before a restore is ever needed, since each one can invalidate a snapshot that looks healthy.

Hypervisor snapshot consistency

Confirm how your hypervisor captures a snapshot of a running FreeIPA server. Find out whether it quiesces the guest filesystem, whether it captures memory state, and whether the directory server and Kerberos KDC are written to a consistent point. A crash-consistent snapshot of a running 389 Directory Server may need validation before it is trusted. Test a restore in an isolated network and run the health checks against the result.

FreeIPA and OS release in the snapshot

Record the exact FreeIPA package version and the operating system release inside each snapshot, not just the version you run today. A snapshot taken before an upgrade restores the older server, and the replicas it rejoins must still be compatible with it. Keep a note of the release notes and security fixes that landed after the snapshot date, such as the 4.13.4 CVE fixes, so you know what the restored server is missing.

Outdated backups in your topology

The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Decide whether a snapshot from one server can be brought back while its peers keep running newer data. If your environment has several live replicas, a single rolled-back VM is likely to diverge from them. Plan the restore as a topology decision, not a file copy.

CA and CRL state after restore

The first server handles certificate renewal and CRL publication by default. Check which server holds that role in your deployment and whether the snapshot predates recent renewals or revocations. A restored CA can issue or publish from stale state, and certificates renewed on another server after the snapshot may be missing from the restored copy. Verify the CA state and CRL output before you return the server to service.

DNS and time synchronization

Confirm that the restored server resolves the same zones and that its clock is synchronized with your time sources. Kerberos depends on tight time agreement, and a snapshot restored into a different network segment can carry stale time or DNS records. Check the DNS records FreeIPA publishes for the server and that clients still reach at least two DNS servers after the restore.

Replica count per datacenter

Count the replicas you actually run in each datacenter and compare that with the project's recommendations. The guidance advises at least two to three replicas in each datacenter and no more than four replication agreements per replica. A snapshot strategy that covers only one replica leaves the others to re-synchronize, and a topology with fewer copies gives you fewer intact sources to compare against. Document the layout before you choose which servers to snapshot.

How DeployOpen scopes and delivers FreeIPA recovery work

DeployOpen plans, implements, backs up and documents self-hosted open-source platforms inside your own infrastructure, so FreeIPA disaster recovery with VM snapshots is handled in your cloud accounts or data centers. We start from a written scope that names the failure scenario, the snapshot mechanics and the replication checks you need before any work begins.

How we scope

We confirm which failure scenario applies: snapshot-only, partially working, or a new environment.
We inventory every FreeIPA server, its roles, its snapshot store and its replication agreements.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We document the snapshot procedure for each server and confirm consistency with the directory and CA state.
We rehearse recovery in a non-production copy before touching the live topology.
We verify Kerberos, DNS, certificate issuance and client logins after each restore step.

How we hand over

You receive a runbook covering snapshot schedules, restore order, and replica re-initialization steps.
You receive replication and health check results recorded at the end of each test run.
Your team walks through a supervised recovery drill so operators know each decision point.

How we support

Ongoing support, upgrades and recurring testing are available as a retainer.
We review the runbook after FreeIPA release updates that change backup or replication behavior.
We keep snapshot retention and restore tests aligned with your change calendar and audit needs.