hh-media.net

KeePassXC backup: a file that opens can still be out of date

A KeePassXC backup can open without an error and still hold information from an earlier day. In our recorded lab, a native encrypted backup opened in a fresh application profile, and the stored fields matched the baseline for all five fictional entries. One note that was changed after the backup was made was absent from the restored copy. The file opened; the information was old.

What the video asks

The video works through one question: how do you know that a backup you can open is a recovery point you can actually use? It looks at three actions in a fixed order (save a native encrypted backup, change one note in the working database, and later open a copy of that backup in a fresh application profile) and at three checks on the result.

The video is built on a lab recording that was already made. It reuses that recording. It is not a new test, and the measured numbers below come from that earlier lab.

What we tested

Tested: KeePassXC 2.7.10 on Linux, in a recorded lab with fictional data only. For each of the five fictional entries we checked five fields: title, username, dummy password, URL and notes. The result covers those selected fields, not every feature of a KeePassXC database.

The working database and the backup were in separate folders on the SAME disk. This is a lab recovery workflow. It does not test disk-failure protection, offsite storage, or resistance to attacks. Attachments, custom icons, passkeys and hardware-key recovery were not tested.

What the restore showed

The backup was a native KDBX file. We changed one note in the disposable working database, then moved that working file out of its original path. We opened a copy of the backup in a fresh application profile.

One intentionally wrong password was rejected before the correct demonstration password opened the copy. This means a copied encrypted backup still needs the credentials you would have during a recovery.

The copy opened without an error. The stored fields matched the baseline for all five fictional entries, and the note that was changed after the backup was absent. The backup and the copied restore file also had matching checksums.

So the restore was successful in the narrow sense of the test, and it still returned an older recovery point. A completed copy of a file is not the same result as a recovery point you can use.

Three checks on a backup

The video turns that result into a short check you can do yourself:

If the bytes do not match, or the copy was never checked, the first check has already failed. If a later change is missing from the copy, the file may still be correct and still too old for your purpose. The video treats this as a decision aid for your own backups, not as a new measurement.

What this lab did not test

The lab did not test a corrupted copy, or a database that will not open with the correct password. It did not test disk failure, offsite storage, cloud synchronisation, or attacks on the file. It did not test key-file or hardware-key recovery. The fixture used a password only.

Different folders on one disk do not demonstrate survival of a failed disk. Practice the restore on fictional data first, and protect a restored real backup as carefully as the original. We do not promise guaranteed recovery.

Native backup is not a CSV export

The official user guide states that a CSV file is unencrypted and that you should securely delete it after you import it. It also records format limitations for exports. These are documented statements, not measurements from our lab, and we did not test those limitations here.

The backup in our test was a native KDBX database file, not a CSV export. An encrypted native backup still needs a credential you keep safe and separate.

A practical recovery checklist

Locate a native backup and check when it was made. Copy it to a separate test location without replacing the working database. Check the checksum of the copy. Open the copy with the credentials you would have during a recovery, and look at the entries and fields that matter to you. Then check what changed after that backup was made, and decide whether that recovery point is recent enough. Finally, check whether your storage arrangement covers the failures you care about.

Sources and versions

Source checks for this page: 20 October 2026. The user guide showed version 2.7.11 and the download page showed version 2.7.12. The version tested in the lab was 2.7.10. These are dated observations, not a claim about the current release.

Chapters

Transparency

Narration is AI-generated from Henrik's own recorded voice. The application footage and recovery checks are real. No sponsorship or affiliate links were added to this video package. This page uses ordinary links and a locally hosted thumbnail, not an embedded YouTube player.

The published video points to the earlier, longer recording of the same lab, KeePassXC Backup Test: Can You Recover Your Passwords? (7:38). For the broader choice between local and hosted password managers, see our password-manager comparison. Our disclosures and privacy page remain available.