Quick answer
Compare a SHA-256 digest recorded from the source with the downloaded copy, test the correct archive format and inspect its contents. Those checks establish transfer and preliminary readability; only a controlled restore can show the website and data work.
What you can prove before a restore
A downloaded backup needs three preliminary checks: source comparison, format readability and expected contents. None establishes application recovery alone. Keep the source unchanged and use an isolated restore test before relying on the copy for a risky operation.
This guide covers a backup file already created by an authorised site owner or operator. It does not describe creating the backup or restoring into a live account. The website-backup checklist helps decide which components you need; the separate restore-test guide covers the application test. Your Novasean service, backup tool and account permissions determine which files and controls you can access.
Identify the source file and recovery point
- Confirm that the backup job completed without an error. Record the source account, backup filename, creation time with time zone, selected components and the intended site. Keep any associated database export with the same recovery set.
- Download to an authorised location outside the live hosting account. Keep the original file unchanged while you verify it. Restrict access: a hosting backup may contain databases, mail, passwords or other private data.
- Check the downloaded file is present and has a plausible non-zero size. Compare its size with the source where the interface shows one. A size match alone does not prove that the contents are correct.
DirectAdmin describes its account backup as a tar.gz archive, but user-level options can include or omit website files, database settings and data, email accounts and messages. Other backup products may use another format or encryption. Use the tool for the actual format; do not rename an unfamiliar file to .tar.gz merely to make a test run.
Compare a checksum made before and after transfer
If you can calculate a SHA-256 digest on the source copy before downloading, save that digest in a separate protected record. Calculate SHA-256 on the downloaded copy and compare all 64 hexadecimal characters. On Linux, sha256sum backup.tar.gz prints the digest; on macOS, use shasum -a 256 backup.tar.gz; in Windows PowerShell, use Get-FileHash -Algorithm SHA256 -LiteralPath 'backup.tar.gz'. Use the real filename and run the command in a private directory. If the source is managed by someone else, ask its operator for a digest calculated from the source file. Some panels do not expose one.
If the values differ, stop: the downloaded file is not byte-for-byte identical to the source file used for the first calculation. Preserve the source and retry the transfer, then compare again. A digest calculated only after download is useful for detecting later changes to that local copy, but it cannot prove that the transfer matched its source. A matching digest also does not establish that the source backup contained every required component.
Read the archive without extracting over a site
For a genuine unencrypted tar.gz file on a trusted machine, tar -tzf backup.tar.gz lists its member names and reads the archive without extracting it. An archive test that exits with an error is a failed check; do not hide errors by piping the output through another command. Inspect the names privately for the site and components you expected. For a large archive, an authorised operator can save the listing in a protected location and check the command's exit status. Archive names may disclose account or customer details.
Do not unpack an unfamiliar or untrusted archive into the live web root, an existing account or a directory that holds important files. Listing does not prove that a database import will succeed, that application versions are compatible or that all files from the intended recovery point were captured. If the format is not tar.gz, use the backup product's supported integrity check instead of this command.
Match the contents to the recovery goal
Compare the archive listing and any separate exports with your backup inventory. For a database-backed site, find evidence of both site files and the matching database export; for hosted mail recovery, check whether mail data was selected rather than only account settings. Record anything held by another provider, such as external DNS or a SaaS service, as a separate recovery dependency. Avoid opening or sharing raw customer records just to satisfy this check.
Mark the file unverified if its source or recovery point is unclear, the checksum differs, the archive reports an error or a required component is absent. Keep the last known good copy and ask the responsible operator to diagnose the failed backup or transfer before any production restore. A clean result means the downloaded copy passed preliminary checks; arrange a controlled restore to a separate authorised target to prove the application and representative data work.
Example: a local checksum has a limited meaning
If you calculate SHA-256 only after downloading, you can detect later changes to that local file, but cannot prove it matches the source. Obtain the source digest independently where available, compare all 64 hexadecimal characters, and keep the source backup intact if the values differ.
If the digest matches but the archive lacks the database, the transfer passed and the recovery inventory failed. Record those as separate results. Preserve the copy, locate the missing export and postpone any destructive restore.
Record the result and the next test
Record the backup identifier, source and destination, timestamp, expected components, checksum comparison if available, archive test result, missing items and the person who checked it. Store that record separately from the backup and keep both under the agreed access and retention rules. Do not paste an archive, database export or credentials into an ordinary support request.
Does a matching SHA-256 value mean the website can be restored? No. It compares two file copies; it does not verify the source backup or application recovery. Can I skip a restore test when the archive opens? No if you need assurance that the site can run. Use the isolated restore-test guide and check representative files, database-backed content and dependencies. What if my backup is a VPS snapshot rather than a file? Ask the platform operator for the snapshot's supported verification and restore method; a tar.gz command does not apply.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.