Protect the source and current site first
Preserve the backup and current data, then distinguish an active job, a failed restore and a completed job with missing components.
A partial restore can change one component while leaving others untouched. Stop before starting the same restore again. Keep the original archive and any separate copy; do not delete the present site or its database to make room. Record the last known working time, the backup date and time zone, and changes made after that backup. If the site is serving customers, tell the application owner what is failing and agree who can approve an overwrite.
This guide diagnoses a DirectAdmin account-backup restore, not a Virtualizor VPS image restore. A backup present in a panel does not prove that it is complete or that your Novasean service includes operator-managed recovery. Check your actual account permissions and agreed service scope.
Find out what the restore actually did
- Identify the exact archive, account, destination and components selected for the attempt. Do not assume a backup from another account or server has the same contents or permissions.
- Record the start time, visible status, progress and exact error or message. The DirectAdmin Admin Backup/Transfer interface can show an In Progress view where available; a User-level account may not expose that view. Ask Novasean to check the job and administrator-side details if you cannot see them.
- Compare the present site with the expected state: can the domain serve a page, does the application connect to its database, and are mailboxes involved? Treat a completed panel task and a working application as separate checks.
DirectAdmin runs a restore as a background task after the panel starts it. A still-running job, a failed job and a completed job with an incomplete application require different next actions. Do not start a second restore while the first job may still be active.
Classify the first failure before changing anything
No job or usable archive appears
Check that you selected the intended backup and account, that the archive still exists and that your account is allowed to use this restore route. Ask the operator to check file readability, ownership and the actual task queue. Do not rename an archive or alter ownership yourself merely to make it appear in a list.
The job stops during extraction or data transfer
Capture the first error and the affected component. Free disk space, account quota, temporary working space and a remote transfer can each be different constraints. DirectAdmin documents backup space and quota behaviour, but an error mentioning space does not tell you which limit failed. Ask the operator to check the destination and temporary location before a controlled retry. Do not disable quotas, remove existing data or weaken a firewall as a guess.
The panel says complete, but the site is still broken
Compare the restored components with the application needs. Site files without a matching database, or an account without the expected database user and privileges, can leave a database-backed site unusable. Check the application error without exposing secrets; confirm the expected database name and user with the application owner. Also check the exact hostname, DNS destination and HTTPS separately: a restore does not by itself correct external DNS or a proxy pointing elsewhere.
Choose one controlled recovery path
If a job is still running, wait for its final status or ask the operator to investigate a genuinely stalled job. If it failed, preserve the first error and correct only the identified cause. If it finished but a component is missing, compare the archive contents and selected restore scope before considering a targeted restore. Keep a separate copy of the current state and prefer an isolated authorised test destination when the application is important or the overwrite effect is uncertain. The restore-scope guide helps choose between a file, matched application data and an account restore; the isolated restore guide explains a safe rehearsal.
Do not repeatedly restore the same archive to production to see whether a different result appears. A second attempt can overwrite data created after the first attempt and obscure the original failure. If the error points to server-side settings, storage, conversion or database import, let the authorised operator investigate rather than changing DirectAdmin administrator settings from a customer guide.
Verify recovery against the original goal
- Check the final job status and any reported skipped or failed components.
- Open a known page over the intended HTTPS hostname and test one read-only application action that needs the database. Confirm files and database belong to the same recovery point.
- If mail was within scope, confirm the expected account and a sample folder or message without sending test mail to real customers.
- List legitimate uploads, orders or other changes since the backup and agree how they will be reconciled. Keep the preserved pre-restore state until the application owner accepts the result.
A green job status alone does not establish that every customer-facing function or newer change is safe.
For example, restored files with a failed database import can leave a cached home page looking healthy. Verify a read-only database-backed action and reconcile newer records before the owner accepts recovery.
Give support the evidence needed to unblock the restore
Send Novasean the service and account identifier, archive name and date, requested restore scope and destination, attempt start time and time zone, visible status, the first exact error, affected components, current website impact and the application owner who can approve data loss. Ask which step failed, whether the original job is still active, which storage or permission boundary applies, and whether an isolated test is possible. Do not attach the full backup, private keys, passwords, DNS API tokens or customer data to an ordinary ticket; arrange an approved secure transfer if the operator needs the archive.
Should I delete the old backup to free space? Not until another verified copy and the recovery plan make that safe. Does a completed restore prove the site is recovered? No; test the actual application and any mail or database components in scope. Can I rerun the job immediately? First establish its final status and fix the identified cause so a retry does not overwrite newer data or conceal the first error.
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.