EN Test a backup by restoring files to a separate folder
Contents
At a glance
Check a backup without overwriting your originals: choose a snapshot, restore a sample, compare files and record what the test actually proves.
Define the recovery you need to prove
A backup job marked successful tells you that the program completed a task. To establish whether the copy meets your needs, retrieve files from it and use them. This guide describes a non-destructive rehearsal for ordinary documents, photographs and exported records. It does not cover restoring an operating system, repairing a damaged repository or recovering a live database. Those tasks need their own procedures.
Choose the situation you want to rehearse: accidental deletion of a document, loss of the computer or a need to return to an earlier version. Write down the folder, required version and acceptable recovery time. A test that retrieves yesterday’s document does not prove you can recover an archive from last year. Include several representative files: a small text document, an image and a larger file, together with a subfolder. Use disposable sample data for your first attempt.
Record where the backup resides and which program created it. For an encrypted repository, confirm you can obtain the password through a protected route independent of the original computer. Do not paste that password, cloud credentials, recovery phrases or private keys into your test report. Kopia’s documentation warns that its repository password is necessary to restore the files. [1][3]
Prepare a destination that cannot overwrite the originals
Create a new empty destination outside the original folder and outside the backup repository. Give it a name that identifies it as a restore test. Check the full path before you confirm the operation. Restoring over the source makes it harder to distinguish recovered files from originals and can replace data you wanted to keep. Do not use an automatically synchronized folder for the first rehearsal: restored files could propagate to other devices.
Check available space for the selected files and any temporary work the program performs. Confirm the storage is connected and readable. For cloud backups, check download limits and possible retrieval charges before choosing a large sample. Kopia lets you choose storage, but you arrange and pay for that storage yourself.
If you are rehearsing loss of the computer, also document how you would install the correct backup application and reconnect to the repository on another trusted device. Merely opening a repository already connected on your current machine does not test that part of recovery. Keep the rehearsal limited to resources you own or administer; do not change production credentials, retention rules or access policies just to make a test pass. [1][3]
Check the repository before restoring
Read the verification options in the documentation for your installed version. A structural check and a complete read of stored data answer different questions. Restic’s check command checks repository consistency; its read-data option also reads data packs. The default Kopia snapshot verification checks structures and the presence of required blobs, but stops short of downloading, decrypting and decompressing every file.
Kopia documents a verify-files-percent option for reading file content during verification. Selecting 100 requests verification of all files, with corresponding traffic and processing costs. It does not create a lasting restored working folder. Choose a scope you can afford and record the setting rather than writing only “backup checked.” Follow the current command help instead of copying flags from an unrelated program.
If verification reports missing or corrupt data, preserve the log and stop treating this copy as proven recoverable. Do not begin by deleting snapshots or running a repair command you have not understood. Keep any other copies intact. This guide deliberately separates a recovery rehearsal from repository repair, because a repair can change the evidence and requires a plan specific to the failure. [2][4]
Restore a specific snapshot
List the available snapshots and choose an exact identifier or timestamp. Check that the chosen snapshot contains the intended folder and predates the change you want to undo. The most recent snapshot may already include an accidental deletion. Record the selected version before starting the restore so that another person can reproduce the result.
In KopiaUI, use the restore operation for the selected snapshot and inspect the destination shown before confirming. With Restic, follow the documented restore workflow and specify a separate target directory. This article does not prescribe one universal command: repository authentication and paths depend on your setup. Never replace a destination placeholder with your live source directory merely because that path is familiar.
Wait for the operation to finish and retain the result, including warnings and files that could not be restored. A progress bar reaching the end is not enough if the log reports skipped items. Do not delete the originals to make the rehearsal seem realistic. You can test an older version by changing a disposable sample after its first backup, making another snapshot and then restoring the earlier one to your test folder. [3]
Inspect files and measure the result
Inspect the restored directory tree and compare it with the intended sample. Check filenames, expected subfolders and file sizes. Open the text document and read its contents, open the photograph and view it, and open the larger document with its normal application. A file’s presence alone does not show that you selected the right version or that the application can read it.
Where you have a trusted reference copy, compare cryptographic hashes to check byte-for-byte equality. Use the reference for the version you restored: a mismatch against a deliberately changed current file is expected. Matching hashes do not prove that the original document was correct, malware-free or complete before it was backed up. Keep that distinction in the record.
Measure how long access, download, restoration and inspection took. Note any missing permissions or metadata that matter to your use case. Ordinary file testing does not establish database consistency or system bootability. If you tested a sample, describe the result as a successful sample restore, not a guarantee covering every snapshot and every possible failure. Escalate unexplained differences before depending on this copy. [2][3]
Keep a recovery record and repeat the test
Save a short record containing the test date, application version, repository label, snapshot identifier, selected files, destination, verification settings and outcome. Record duration and unresolved warnings. Keep secrets out of screenshots and logs you plan to share. A useful result is specific: a named snapshot restored a stated sample into a separate directory, and the files passed the checks you recorded.
Repeat the rehearsal after changing storage providers, encryption credentials, backup software or retention rules, and choose a routine interval appropriate to the importance of the files. Include older snapshots when historical recovery matters. Confirm that any person expected to perform recovery can locate the instructions and obtain authorized access without relying on the failed machine.
Remove only the disposable restored test folder when you no longer need it, after checking its full path. Do not delete the repository or alter retention as part of cleanup. Keep the recovery record and improve the instructions where you encountered uncertainty. The objective is a repeatable recovery procedure with explicit limits, supported by actual restored files rather than an unchecked success notification. [2][3]
Frequently asked questions
Should I delete originals for the test?
No. Restore into a separate empty folder and leave the originals untouched. [3]
Does checking metadata read every file?
Not necessarily. Read the selected verification mode; full data checks and actual restoration have different effects. [2][4]
Does a sample restore prove all backups are usable?
No. Record the snapshot and sample tested, and repeat with other relevant versions. [3]
Evidence & sources
Source record: · Checked:
- Source reported
Kopia requires the repository password to restore files.
Supporting excerpt: Kopia: getting started
There is absolutely no way to restore any of your backed up files from a repository if you forget your password!
Kopia: getting started ↗ - Source reported
Kopia recommends regular snapshot recovery tests.
Supporting excerpt: Kopia: snapshot verification
you need to test snapshots regularly
Kopia: snapshot verification ↗ - Source reported
Restic documents restoration to a separate target path.
Supporting excerpt: Restic: restoring from backup
restore the contents of the latest snapshot to /tmp/restore
Restic: restoring from backup ↗ - Source reported
Restic distinguishes structural checks from reading stored data.
Supporting excerpt: Restic: repository checks
Structural consistency and integrity
Restic: repository checks ↗
Related reading
DOJ seizes crypto in ‘ghost student’ fraud case
US prosecutors announced a cryptocurrency seizure and charges over stolen identities used for student aid. The release does not establish repayments to victims.
Read article : DOJ seizes crypto in ‘ghost student’ fraud case
OneCoin: what the June 2026 FBI remission notice said
The official notice identified eligibility, a free application process and a deadline that must not be presented as still open.
Read article : OneCoin: what the June 2026 FBI remission notice said
OneCoin: separate a compensation notice from a recovery pitch
An official process has a defined authority and terms; scammers can imitate its appearance without acquiring that authority.
Read article : OneCoin: separate a compensation notice from a recovery pitch