Backup Verification

Detect corrupted or tampered backup files before you need to restore them.

Why Verification Matters

A backup that silently corrupts mid-upload is worse than no backup at all - you only discover the problem at the worst possible moment, during a restore. Verification catches this early by comparing a cryptographic checksum of the backup file against the original value recorded immediately after the dump.

How It Works

Checksum Generation (at upload time)

After every backup DBackup computes a SHA-256 and an MD5 checksum of the final .tar in one pass, the file exactly as it is uploaded. Google Drive is checked against the MD5, every other destination against the SHA-256.

Both values are stored in the .meta.json sidecar file alongside the backup:

{
  "checksum": "a3f1b2c4...",
  "checksumMd5": "d8e9f0a1...",
  "verification": {
    "verifiedAt": "2026-06-10T14:32:00Z",
    "passed": true,
    "trigger": "post-upload"
  }
}

Verification Logic

When a verification is triggered, DBackup uses the best available method for each storage adapter:

Adapter	Method	No Download Needed
Local Filesystem	Direct file hash via stream	Yes
S3 / R2 / Hetzner	HeadObject - reads SHA-256 from object metadata	Yes
Google Drive	files.get API - reads native MD5 field	Yes
OneDrive	Graph API - reads native SHA-256 hash	Yes
SFTP / FTP	Download + compute SHA-256	No
SMB	Download + compute SHA-256	No
WebDAV	Download + compute SHA-256	No
Dropbox	Download + compute SHA-256	No
Rsync	Download + compute SHA-256	No

For adapters without native checksum APIs, DBackup downloads the full file, recomputes the hash, and compares it against the stored value.

The result is written back into the .meta.json sidecar so it persists across sessions and appears immediately on the Backups page without re-verifying.

Triggering a Verification

Manual Verification (on-demand)

In the Backups page, open the menu at the end of a backup's row and pick Verify integrity, or click Verify in the panel a click on the row opens. The dialog lists every copy of the backup, one per destination, with:

• where the copy lies, and whether that destination answers right now
• how it is checked: by the checksum the destination keeps, without a download, or by downloading and hashing it, with the size that moves
• its last check, with when and what ran it: after the upload, by the weekly check or by hand
• Passed, Does not match, Not checked, or Missing for a copy whose upload failed

Verify on a row checks that copy, Verify all checks every copy there is. The copies with a checksum of their own go first, since they take seconds, the downloads after them. The dialog shows each copy while it is checked, with the bytes of a download, and closing it does not stop the check. It runs as one entry in History, and Open in History leads there.

A copy that does not match shows at the top of the dialog. A restore or a download reads from a copy that passed, and the broken one can be verified again or deleted, so the next run of the job writes it anew. Stored checksums unfolds the SHA-256 and MD5 the upload recorded, each with Copy.

Re-verify anytime

You can verify a backup again at any time, one copy or all of them.

Post-Upload Verification (automatic)

Right after the upload, DBackup checks every copy on a Local Filesystem destination. The check is a direct file read with near-zero overhead.

Copies on remote destinations are not checked after the upload. The runner only checks them while the system setting backup.postUploadVerify is true, and no page in DBackup sets it. Verify them by hand or with the scheduled integrity check below.

Bandwidth for download-based adapters

For SFTP, FTP, SMB, WebDAV, Dropbox, and Rsync, every check downloads the full backup file again to recompute the hash. For large backups on slow or metered connections this adds significant time and transfer costs. For S3, Google Drive, OneDrive, and local storage, a check has near-zero overhead.

Scheduled Integrity Check

The Integrity check system task periodically verifies all backups across all storage destinations. It runs through each destination, reads the .meta.json sidecar for each backup file, and runs the same native-first verification logic as the manual check.

Results are written back to the sidecars as they complete, so the Backups page badges stay up to date without any manual action.

A destination whose Integrity checks are off in the Behavior part of its form is left out, and an air-gapped destination is checked whenever it is connected. Several destinations are switched at once: tick them on the Destinations tab of Connections and pick Turn off integrity checks or Turn on integrity checks under More.

It is off by default and its default schedule is every Sunday at 4 AM. Its switch and schedule are under Settings > System tasks.

What counts as "scheduled"

The trigger field in .meta.json records how each check was triggered: manual, post-upload, or scheduled. This lets you distinguish between a fresh post-upload check and an older scheduled check in the metadata.

Interpreting Results

Status	Meaning
Verified (green)	File matches its checksum - no corruption or tampering detected
Failed (red)	Hash mismatch - file may be corrupted or was modified after upload
No checksum	Backup predates checksum support - no baseline to compare against
No metadata	File has no .meta.json sidecar (manually placed file)
- (dash)	Never been verified

A Failed result does not necessarily mean the backup is unrestorable - it means something changed since the original upload. Possible causes:

• Storage provider-level corruption (rare but documented on HDD-backed storage)
• Partial re-upload or file replacement
• Ransomware or accidental modification
• Network error during original upload that was not caught

If you see a failed check on a backup you intend to use for a restore, treat it as suspect and try an older backup if available.

Limitations

• Encrypted backups: The checksum covers the encrypted file, not the plaintext. A passing integrity check confirms the encrypted bytes are intact, but does not guarantee the decryption key is still available.
• Legacy backups: Files uploaded before checksum support was added have no baseline. Verification will report "No checksum" and no comparison is possible.
• Native SHA-256 on S3: The SHA-256 is stored as S3 custom metadata (dbackup-sha256) during upload. If the object was copied or re-uploaded via external tools without preserving this metadata, native verification will fall back gracefully and report "unsupported" - which triggers a download-based check instead.

Next Steps

• Backups - Browse and manage backup files
• Restore - Restore a backup to a database
• Encryption - Encrypt backup files at rest