Partial and point-in-time restores - one file, one directory, one moment · Linux

The full-system restore is the one that gets rehearsed. The partial restore is the one that actually happens: somebody deleted a config file, a deployment overwrote a template, a table was truncated by a migration that was supposed to be read-only.

It has a completely different risk profile. The host is up. The service is running. Other people’s changes are live in the same directory you are about to write into. The failure mode is not “the restore did not work” - it is “the restore worked and took three weeks of unrelated changes with it”.

Rule one: never restore onto the live path

Configuration changestage first— A staging directory named after the ticket, on the same filesystem as the target so the final move is atomic, mode 700 because the restored files may include secrets and the staging directory has no reason to be readable. Everything else in this lesson extracts here first. The only step that touches the live path is a reviewed move at the end.

$ sudo mkdir -p /var/tmp/restore-1842 && sudo chmod 700 /var/tmp/restore-1842

Extracting into a staging path costs one directory and buys three things: you can diff before committing, you can abandon the restore with no trace if it turns out to be the wrong version, and the live service keeps running on the files it already has while you decide.

Read-only / Safethe review step that saves the restore— Two findings in one diff. The backup predates a tuning change somebody made in July, so restoring the whole file reverts it. And sites-enabled/reporting.conf exists only on the live host - a site added after the backup, which a directory-level restore with --delete would remove. Neither is visible without this comparison, and both are what turns a five-minute restore into an incident.

$ sudo diff -ru /etc/nginx /var/tmp/restore-1842/etc/nginx

diff -ru /etc/nginx/nginx.conf /var/tmp/restore-1842/etc/nginx/nginx.conf
--- /etc/nginx/nginx.conf	2026-08-11 09:14:02.000000000 +0000
+++ /var/tmp/restore-1842/etc/nginx/nginx.conf	2026-07-21 02:00:11.000000000 +0000
@@ -18,7 +18,6 @@
worker_connections 4096;
-    multi_accept on;
}
Only in /etc/nginx/sites-enabled: reporting.conf

Illustrative output

The restore that reverted three weeks of other people's work

The shape is always the same. A file is broken today. The backup from three weeks ago is known good. It gets copied over the live file, the immediate problem goes away, and the ticket is closed.

What also went back three weeks: a TLS cipher list hardened by the security team, a rate limit added after an incident, an upstream added for a service that launched last week. None of them are related to today’s problem, none of them are mentioned in the ticket, and all of them are now gone. The next failure happens days later and is attributed to something else entirely.

The fix is not more care. It is a step:

sudo diff -u /etc/nginx/nginx.conf /var/tmp/restore-1842/etc/nginx/nginx.conf

Read the diff and take only the hunk you came for. If the diff is too large to read, that is information: the file has diverged enough that a wholesale replacement is a bigger change than the one you were asked to make, and it needs the owner’s agreement rather than yours.

Browsing a repository without extracting it

Finding the right version is most of the work, and every deduplicating backup tool can list and read individual paths without restoring anything.

Read-only / Safewhich archives exist— borg list against the repository enumerates archives; borg list against a single archive enumerates its contents. Neither extracts anything. The restic equivalents are 'restic -r /backup/repo snapshots' and 'restic -r /backup/repo ls <snapshot-id> /etc/nginx'.

$ borg list /backup/repo

backup-2026-08-11T02:00:04  Tue, 2026-08-11 02:00:04 [3f9a...]
backup-2026-08-10T02:00:03  Mon, 2026-08-10 02:00:03 [7c2e...]
backup-2026-07-21T02:00:11  Tue, 2026-07-21 02:00:11 [b418...]

Illustrative output

Configuration changebrowse the archive as a filesystem— borg mount presents an archive read-only over FUSE, so ordinary tools work on it: ls, diff, grep, cp. Nothing is extracted until a file is read, which makes it far cheaper than a full restore for finding the version you want. Unmount with 'borg umount /mnt/borg' when you are done - an idle FUSE mount holds a lock on the repository and blocks the next backup. restic has the same facility as 'restic -r /backup/repo mount /mnt/restic'.

$ borg mount /backup/repo::backup-2026-07-21T02:00:11 /mnt/borg

Borg stores paths without their leading slash, and extracts relative to the working directory

This is the mistake that produces a restore in the wrong place, and it produces it silently.

Paths inside a Borg archive have no leading /. Asking for /etc/nginx/nginx.conf matches nothing and extracts nothing, with no error that reads like an error. The path to ask for is etc/nginx/nginx.conf.

And borg extract writes relative to the current working directory. Run it from / and it overwrites the live system. Run it from a staging directory and it does the right thing:

cd /var/tmp/restore-1842
borg extract --list /backup/repo::backup-2026-07-21T02:00:11 etc/nginx/nginx.conf

--dry-run with --list shows exactly what would be written before anything is. Make that the first invocation every time, and never run borg extract from / unless overwriting the live system is precisely and deliberately what you intend.

restic behaves differently and needs its own habit: paths keep their leading slash, and --target is mandatory rather than implied by the working directory.

restic -r /backup/repo restore b4180000 \
  --target /var/tmp/restore-1842 --include /etc/nginx

Finding the last good version, not the last version

The newest backup contains the damage. That is normally the whole reason there is an incident: the file was corrupted or deleted at some point, and every backup since has faithfully captured that state.

Establish when the damage happened, from the application log, the deployment record or the shell history - not from the backup timestamps.
List the archives that bracket that moment. The last backup before it is the candidate.
Verify the candidate before committing to it. Read the file out of the archive and check it is actually intact - a slow corruption may predate the incident you noticed.
If the boundary is unclear, walk backwards. Compare consecutive archives and find where the file changes shape rather than content.

Read-only / Safewhat changed between two snapshots— restic diff compares two snapshots and reports added (+), removed (-) and modified (M) paths. It is the fastest way to bracket when a file changed without extracting either version, and it turns 'which backup do I want' from a guess into a lookup. Borg has no equivalent single command; compare 'borg list' output for the two archives instead.

$ restic -r /backup/repo diff 7c2e0000 3f9a0000 | grep nginx

M    /etc/nginx/nginx.conf
+    /etc/nginx/sites-enabled/reporting.conf

Illustrative output

Point-in-time recovery for databases

“Restore the file” has no meaning for a database. The unit is a consistent state at a moment, and reaching an arbitrary moment needs two ingredients: a base backup taken before it, and the write-ahead log covering the interval from the base backup to the target time.

PostgreSQL calls it PITR and drives it from configuration, not from a command:

# postgresql.conf on the RECOVERY instance - not the live one
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2026-08-11 09:12:00+00'
recovery_target_action = 'pause'

# the recovery.signal file is what puts the instance into
# targeted recovery; PostgreSQL 12 and later have no recovery.conf
sudo -u postgres touch /var/lib/postgresql/16/restore/recovery.signal

Recover into a new data directory, never into the live one

Point-in-time recovery rewrites the cluster state. Pointing it at the running data directory does not give you a choice about the result - the moment the instance starts replaying WAL, the current data is gone and the only way back is another restore.

The safe shape has three properties:

A separate data directory. Restore the base backup into /var/lib/postgresql/16/restore, not into .../main.
A separate port. Start the recovery instance on 5433 so nothing connects to it by accident and no application config needs changing to reach it.
recovery_target_action = 'pause'. The instance stops at the target and waits, so you can connect, inspect, and confirm you picked the right moment before promoting it with pg_wal_replay_resume(). The alternative, promote, makes the decision for you and there is no second attempt without restoring the base backup again.

Only after the paused instance has been inspected and the data confirmed does the cutover happen - stop the live instance, move directories, start on the real port. Two things have to be true before that: you know what data the target time actually contains, and you have decided what happens to the writes that occurred after it.

MySQL and MariaDB reach the same place from the other direction: restore the full backup, then replay the binary log up to the moment.

mysqlbinlog --start-datetime='2026-08-11 02:00:00' \
            --stop-datetime='2026-08-11 09:12:00' \
            /var/log/mysql/binlog.000147 > /var/tmp/restore-1842/replay.sql

Writing the replay to a file first, rather than piping it straight into mysql, is the same staging discipline as the file case. It is reviewable, it is re-runnable, and it does not apply anything until somebody has looked at it.

Why the diff step matters more than the extract step

A restore is not really a copy operation. It is a merge between two states - what the backup holds and what the live system holds - and the tool only performs the copy half. The merge is a judgement, and it belongs to a person.

That is why rsync --delete deserves particular suspicion in a partial restore. It makes the target match the source exactly, which means deleting anything on the live system that is not in the backup - the file added last week, the socket a running service created, the log the application is currently writing.

# see what --delete would remove, without removing anything
sudo rsync -aHAXn --delete --itemize-changes \
  /var/tmp/restore-1842/etc/nginx/ /etc/nginx/

-n is --dry-run. --itemize-changes prints a code per path, and every line beginning *deleting is something the real run would remove. Read that list before dropping the -n. If it is not empty and you cannot account for every entry, --delete is the wrong flag for this restore.

Rule one: never restore onto the live path

Browsing a repository without extracting it

Finding the last good version, not the last version

Point-in-time recovery for databases

Knowledge check