Limits of svnadmin recover after an interrupted repository format upgrade

Answer

After an interrupted svnadmin upgrade, svnadmin recover can only fix inconsistencies that involve transaction logs, lock files, or partially written proto‑rev files that occur before the format file is changed. It cannot repair mismatches between the new format schema and partially upgraded data structures such as node‑rev tables, pack‑file layouts, or revision‑property streams that have already been altered.

Confirmed facts

• svnadmin recover replays incomplete transactions, cleans stale lock files, and fixes proto‑rev files that were left open when the upgrade was stopped.
• If the format file (db/format) has not yet been updated, the repository is still using the old FSFS layout; running svnadmin recover restores consistency to that old format.
• Once the format file has been updated to the new version, the repository expects the new schema. svnadmin recover does not migrate or roll back data, so any half‑written node‑rev tables, packed‑file changes, or revised property streams remain inconsistent.
• For FSFS repositories created with Subversion 1.8 or later, the upgrade process writes a temporary format file and renames it only after data migration completes. Therefore, if the upgrade is interrupted before the rename, the format file stays old and svnadmin recover can revert; if the rename has already happened, the data migration is finished and the repository is already consistent.

Likely explanation

The upgrade consists of two phases: (1) updating the format file, and (2) migrating existing revision data to the new layout (e.g., packing, property‑stream changes). An interruption after phase 1 but before phase 2 leaves the repository claiming the new format while still holding old‑format data—a state that svnadmin recover cannot reconcile.

Steps to try (when a hotcopy backup is unavailable)

1. Check the current format version: cat /path/to/repo/db/format.
2. If the number matches the pre‑upgrade format, run svnadmin recover /path/to/repo.
3. Run svnadmin verify /path/to/repo to confirm consistency.
4. If verification succeeds, the repository is usable; otherwise proceed to dump/load.

When recovery is not sufficient

• If the format number already reflects the new version, svnadmin recover will not fix the mismatch.
• The supported path forward is to dump the good revision range and load it into a fresh repository:

  svnadmin dump /path/to/repo -r 0:LAST_GOOD > dumpfile
  svnadmin create /path/to/newrepo
  svnadmin load /path/to/newrepo < dumpfile

• Alternatively, if a filesystem snapshot or hotcopy was taken before the upgrade, revert to that copy.

Version‑specific notes

• Subversion 1.8+ makes the format change atomic with respect to the format file, reducing the window where recovery is impossible.
• For older FSFS versions (pre‑1.8), the format file is updated first, so an interruption after that point leaves the repository in an unrecoverable state without a backup.

Missing diagnostic detail

To decide whether svnadmin recover has a chance of success, we need to know the current value of db/format. If it is still the old format number, try recovery; if it is already the new format, proceed to dump/load.