Duplicati Backup Interrupted: Retry Without Data Loss

When a Duplicati backup interrupted message follows an upload timeout, preserve the original backup configuration, local database, and remote files before retrying. First identify the failed operation; then run the same backup through a controlled connection and restore a test file from the resulting version. These precautions reduce avoidable changes, but cannot guarantee recovery from existing damage.

Key Takeaways:

• An interrupted upload and a local database error require different investigations.
• Retrying means running the existing backup again, not creating another job against its destination.
• Keep encryption, storage paths, retention, and the database unchanged during a network comparison.
• The machine running the backup matters more than the browser displaying its web interface.
• Completion needs a restore check from the new version, not only a successful exit or progress bar.

What does a Duplicati backup interrupted result tell you?

It tells you the run did not finish normally; it does not establish which files are recoverable or whether the cause was networking. Duplicati's local database tracks backup information, while the remote destination contains backup data. Deleting one side to clear an error changes the recovery problem.［3］

Use the first meaningful error and its operation to choose a branch. Do not interpret every line containing the word retry as an independent cause. A later failure to verify or clean up can follow an earlier transfer problem.

Evidence from the run	Investigate first	Avoid doing reflexively
Upload request timed out	Destination reachability and execution host	Changing encryption or retention
Authentication was rejected	Correct account and destination permissions	Repeatedly changing routes
Local database error	Database state and the existing job	Deleting the database
Remote file missing or inconsistent	Repository condition with official support	Deleting remote blocks
Source could not be read	Source access and service identity	Treating it as an upload failure

For failures affecting several programs, follow the broader device diagnostic sequence. If the destination uses another transfer tool, separate its retry behavior from destination errors instead of assuming the same message has the same meaning in both applications.

Step 1: Preserve the job and capture the first error

Record the backup name, installed Duplicati version, operating system, start time, destination type, and first failing operation. Save the run report before another attempt changes what is most recently displayed. Identify whether the process was canceled, the computer slept, the service stopped, or an operation returned an explicit error.

Keep configuration and database copies securely. Exports may contain credentials, destination details, and private source paths; redact them before sharing.

Also preserve the actual source files. The existence of a backup job does not mean the interrupted run captured their current state. If this is the only copy of important data, prioritize protecting that copy before conducting experiments or changing backup storage.

Check for a running job before you press Start. Wait for the existing run to finish or use the application's normal cancellation path and confirm it is no longer running. Do not start a second independent writer against the same remote backup while investigating the first one.

Checkpoint: Identify the original task, error, configuration, and database without changing them. Stop if uncertain.

Step 2: Verify the original remote destination and execution host

Open the existing job's settings and compare its storage type, account, bucket or folder, and path with your private record. Do not change the prefix to an empty directory just to make a connection test succeed: that would test another destination and could hide the original problem.

Browser login does not validate Duplicati’s credentials. Check the backup process’s host, service account, source access, and destination permissions.

If you use the built-in connection test, read the confirmation prompts and use it only for the existing authorized destination. Passing it is narrower evidence than a completed backup and restoration. A test can exercise a small request successfully while a larger upload remains interrupted.

Identify where Duplicati actually runs. A web interface on your laptop can control a server, container, or NAS elsewhere. Connecting a VPN on the laptop does not establish that the remote backup writer uses that route. Keep remote execution environments outside a desktop route experiment unless their actual network path is separately understood.

On Windows, review proxy settings and their scope when a proxy is involved. Do not disable certificate validation to accommodate interception, and do not install an unfamiliar certificate supplied by an error page.

Checkpoint: Confirm the original destination, execution host, and account. Private endpoints need their authorized network.

Step 3: Distinguish transfer failures from database problems

Read the operation beside the error rather than inferring cause from the percentage complete. A Duplicati upload timeout supports investigating the transfer path, but a database or permission error needs its own branch. Keep a short timeline showing what failed first and what followed.

Duplicati documents the local database as backup metadata that helps track what is stored remotely. Its restore guide also distinguishes a configured restore using local information from direct restoration that downloads information to build a partial database. A slow information-gathering stage is therefore not automatically a failed file download.［2］［3］

If the report explicitly says a remote file is missing or the database does not match storage, stop the ordinary retry path and seek the applicable official recovery guidance. Do not manually delete remote blocks or select database recreation merely because a general troubleshooting post recommends it. Those are separate recovery operations with different consequences.

The advanced-options reference lists controls for retries, verification, cleanup, and other behavior. It is labeled as migrated community documentation, so check the installed version before using a named option. Do not disable backend verification or raise retry settings without limit just to produce a successful-looking run.［4］

Check local capacity and source availability as well. A service that cannot read a source folder, create temporary work, or access its database can fail while the cloud provider is perfectly reachable. Record those errors separately from the transfer experiment.

Checkpoint: Compare routes only for reproducible connection/upload failures with source, credential, and database issues resolved or excluded.

Step 4: Run one controlled retry of the existing backup

Use the original configured task. The official manual-run workflow starts the selected backup with its Start control; it does not require creating a new configuration. Confirm that no previous writer remains active, then record the run time and resulting report.［1］

Keep the backup's source selection, encryption, remote path, and retention policy intact. Do not shrink the live task by removing source folders to make it faster. For the later restore check, choose a small non-sensitive file already included in this job.

If a public destination repeatedly times out on the machine performing the upload, connect that supported computer through AethoVPN and repeat the original job once. Windows uses the official installer; Linux support is limited to the Debian/Ubuntu x64 .deb; Mac requires the website configuration guide, a VPN client, and Pro or Premium. Choose a nearby available location and enable global mode before restarting the backup. This comparison changes the upload path while retaining the repository and encryption settings; it cannot correct database inconsistencies, replace missing remote blocks, or grant storage permissions.

Create an account to try the original backup upload over another route; new users receive a one-time 3-day Pro trial.

Confirm the VPN with the connection-check procedure, but judge this experiment by the Duplicati run and restore. Compare the first errors on direct and VPN routes. Keep the better working route only after validating the resulting backup version.

If both routes fail at the same database operation, stop changing networks. If only disconnecting the VPN permits the upload, use direct access for this run. Avoid repeated large uploads merely to collect more examples, particularly when the provider meters requests or transfer.

Step 5: Restore a test file from the newly completed version

A successful run is a reason to test recovery, not the end of the investigation. In Restore, choose the existing configured backup, explicitly select the version created by the retry, and select your test file. Restore into a separate empty folder, keeping current source files intact.［2］

Do not leave the version selection implicit. A recovery from an older successful version can conceal a failure to capture the new one. Use a file with a known revision or content marker that distinguishes the intended backup version without exposing sensitive business data.

Review the restore summary and open the result. Confirm the expected contents and check for unresolved errors. The official restore documentation allows choosing another destination to inspect files before replacement; this is appropriate for a diagnostic restore.［2］

Permissions are a separate acceptance item. If a restored file exists but cannot be opened under the current account, investigate destination access rather than declaring the upload unusable. Conversely, a directory listing or a downloaded file that is unreadable does not establish recovery.

Expand to representative data only after the small restore succeeds. It does not validate every version or application consistency; the recovery owner must approve production replacement.

If the retry still fails, send support the installed version, destination type, first error, execution context, and comparison results. Keep credentials and private paths redacted. Preserve the configuration, database, and remote objects until there is an evidence-backed recovery procedure for this specific failure.

Summary

• Keep the existing backup, database, remote files, and source data intact.
• Identify which process and account run the task.
• Separate upload timeouts from database, source, and permission errors.
• Retry the original task once under controlled conditions.
• Validate the resulting version by restoring known content to another folder.

FAQ

Should I delete the database after an interrupted backup?

Not as the first response. Preserve it and determine whether the error actually concerns its state. Database recreation is a separate recovery operation, whereas an upload timeout may require only a controlled retry of the existing job.

Does retrying create a new backup configuration?

It should not. Start the original configured job after ensuring the earlier run has ended. Keep its destination, encryption, and source selection unchanged so you can compare the outcome meaningfully.

What if a connection test passes but the upload fails?

A small connection test does not establish that the entire upload can complete. Record the operation and first transfer error, then investigate its path without assuming that credentials, capacity, and all backend operations were validated.

Can a VPN on the browser computer help a NAS backup?

It does not establish a changed path for the NAS process. Identify the actual execution host and its route. A desktop comparison applies only when that supported desktop is doing the backup transfer.

Which version should I select for the restore check?

Select the version produced by the retry explicitly. Restoring an earlier version proves that earlier content is accessible, but does not show that the interrupted task successfully captured the latest source state.

Does a successful exit code prove the backup is recoverable?

It is useful execution evidence, but not a substitute for a restore check. Verify a known file from the new version, inspect the restore summary, and keep any remaining errors visible in the acceptance record.

When should I stop a Duplicati backup retry?

Stop ordinary retries when missing remote files, database inconsistencies, encryption errors, or uncertain repository identity remain. Escalate with redacted evidence before changing storage structure or allowing another writer to use the same destination.

Disclaimer: This workflow aims to preserve recovery options while diagnosing an interrupted task. It cannot guarantee that an already damaged backup contains every required file.

Sources:

1. Duplicati — Running a backup
2. Duplicati — Restoring files
3. Duplicati — The local database
4. Duplicati — Community docs: advanced options

Sources checked 7 October 2026.