Quick answer
A database-backed website usually needs matching files, database data and configuration to recover. Include uploads and required application objects, and list mail, DNS or external services held elsewhere. Check contents against a real recovery goal and prove the set on an isolated target.
Start with the site you need to recover
Define the site, recovery point and acceptable data loss first. Most database-backed sites require both files and a compatible database copy; a static site may require only deployable files and configuration. The inventory depends on what must work after recovery.
This checklist helps an authorised site owner decide what to capture. It does not mean every item is inside one archive or included in a Novasean plan. Check your service agreement, application and backup tool for the actual scope. The DirectAdmin guide explains how to create and verify an account backup; this guide helps you build a cross-platform inventory.
Make an inventory before you press Back up
| Component | What to identify | How to check the copy |
|---|---|---|
| Website files | Application code, themes or templates, plugins, user uploads and any site-specific hidden configuration files. | Compare important paths and a sample of uploaded media with the live site. |
| Database | Every database the site uses, including tables, routines or other application objects where relevant. | Confirm an export exists, has the expected database identity and belongs to the same recovery window as the files. |
| Configuration | Web-server rules, application configuration, PHP/runtime version, scheduled jobs and integration settings needed to run the site. | Record where each setting is held and whether it is in the archive, a separate export or a controlled configuration repository. |
| Mail, DNS and external services | Only services the recovery objective includes: hosted mailboxes and messages, DNS zone, CDN, payment or SaaS settings. | Identify the actual operator and export or document each separately where its own recovery method allows. |
Do not place passwords, private keys or recovery codes in an unsecured checklist. Store sensitive configuration or exports with access controls and an authorised recovery route.
Check what your backup method leaves out
A web-root download is not normally a database export. A WordPress plugin may cover the application but not mailboxes or a DNS zone operated elsewhere. A hosting control-panel backup may offer separate checkboxes for domain files, database settings, database data, mail accounts, mail data and forwarding settings. DirectAdmin describes those selections for its user-level backup interface; check what was selected and what the completed archive actually contains. An account backup does not necessarily contain server-wide configuration. A VPS snapshot is a different object again: confirm its disk, consistency, retention and restore scope with the platform operator before treating it as your application recovery plan.
Keep an explicit “outside this copy” list. Domain registration, a third-party mailbox, external DNS and SaaS data often have separate owners and export paths. Document how to reconnect them without assuming a hosting backup will restore them. If an HTTPS certificate is automatically issued, record how it will be reissued rather than casually copying a private key into a general archive.
Keep related components at a recoverable point
- Choose the recovery point and record the time zone. For a site that changes while you back it up, coordinate a quiet window or an application-consistent method so the files and database represent a usable state.
- Use the backup method available to your account and select every required component. If the method splits files and database into separate exports, label them as one recovery set with the same target point.
- Wait for a completed job, check its errors and copy the result to an authorised location separate from the live hosting account. A copy stored only inside the account may disappear with it.
- Record the archive names, creation time, covered site, component selection, storage location and responsible person. Set retention and access according to the service agreement and sensitivity of the contents.
Do not assume that a user-level DirectAdmin backup is scheduled automatically. Its documented user-level Create/Restore Backups interface does not itself schedule that job; a separate managed arrangement may have a different schedule.
Prove the set can serve its recovery goal
Check that every expected file or export exists, has a plausible size, can be read and corresponds to the intended date. Inspect a small sample of paths and database objects without exposing customer data. The strongest check is a controlled restore into an isolated environment, followed by a known page load, representative media, a safe database-backed action and any required mail check. A readable archive or successful backup-job message alone does not prove a working site.
If a component is missing, do not overwrite the current site hoping the restore will fill it in. Preserve the existing state, identify the missing operator or export, and ask the responsible application or hosting team for a recovery plan. For a production restore, first decide what the operation will replace, what changed after the recovery point and how to roll back. The separate restore-test guide covers rehearsal without overwriting production.
Example: a WordPress file download is not the whole backup
A download of WordPress files may preserve themes, plugins and uploaded images while omitting posts, users and settings stored in its database. Keep a matching database export with the files. Conversely, a database export cannot recreate a missing upload. Record separately hosted mail and DNS outside that application recovery set.
If the inventory lists a required component with no retrievable copy or recovery route, the set is not ready. Close that gap before a migration or overwrite; an archive name does not show the missing component exists.
Use this five-question check before relying on a copy
- Which exact site and recovery point does this set represent?
- Are the files, database and site-specific configuration all present and compatible?
- Which mail, DNS, domain and third-party services sit outside this copy?
- Can an authorised person retrieve the copy if the live account is unavailable?
- Has a controlled restore shown that the application and important data work?
If you cannot answer one of these, treat the backup as unverified and close that gap before a migration or risky change. Novasean support can help identify the relevant service boundary; do not send an archive or credentials through an unsecured request.
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.