Back up a website: files, database consistency, checksums and recovery metadata

A website backup needs enough information to reconstruct the service, not merely a ZIP file with a recent timestamp. Application files, database state, configuration and operational dependencies must agree. This procedure creates a file archive and a logical database export, then records integrity and recovery information so the result can be tested later.

Define the recovery boundary before copying files

Inventory website code, uploads, private configuration, databases, scheduled jobs, redirects, certificates or renewal configuration, DNS and any external storage. A tar archive of public_html does not automatically include mailboxes, another domain's document root or files stored outside that directory. Document which items the hosting provider's account backup actually includes.

Decide how much recent work you can lose and how long restoration can take. An active shop can update a database and upload a file between two independent copies. Use application maintenance mode or another supported way to coordinate writes when consistency across files and data matters. A completed export is not proof of a transactionally consistent whole-site snapshot.

Create the archive outside the public document root

umask 077
BACKUP_DIR="$HOME/private-backups/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/site-files.tar.gz" -C "$HOME" public_html
tar -tzf "$BACKUP_DIR/site-files.tar.gz" | head -n 20

Confirm that tar completed successfully and that the archive contains the expected relative paths. Replace public_html if the site has a different root, and inventory configuration or upload paths outside it separately. Keeping the archive elsewhere prevents the backup from including itself and reduces the chance that visitors can download credentials or customer data from a predictable URL.

The listing is a quick inspection, not a complete archive test. Check stderr and the command exit status, particularly for unreadable files or files that changed while being read. Do not treat a tiny archive or a nonempty filename as a successful backup.

Export the database with the right consistency model

mariadb-dump --user=backup_user --password \
  --default-character-set=utf8mb4 \
  --single-transaction --quick \
  --routines --events --triggers --hex-blob \
  app_database > "$BACKUP_DIR/database.sql"

The password option prompts instead of placing the secret directly in shell history. Use an export account with the required privileges and choose the actual database. On MySQL, the compatible client is commonly named mysqldump; review the installed client's options and server compatibility rather than assuming every MariaDB option or output format is interchangeable.

Single-transaction gives a consistent transactional snapshot for suitable InnoDB tables, but it does not make MyISAM tables transactional or protect against every concurrent schema change. For mixed engines, arrange a controlled write pause or a provider-supported consistent backup. Routines and events require suitable privileges; inventory them instead of silently omitting objects after a permission error.

Verify the artifacts and preserve their meaning

gzip -t "$BACKUP_DIR/site-files.tar.gz"
test -s "$BACKUP_DIR/database.sql"
cd "$BACKUP_DIR"
sha256sum site-files.tar.gz database.sql > SHA256SUMS
sha256sum -c SHA256SUMS

A matching checksum proves that the bytes match the recorded manifest, not that the data is complete or the application will run. A hash stored beside an archive also does not authenticate the backup against someone who can modify both. Keep protected copies of the manifest and test the actual restore.

Record application and runtime versions, the source database, export method, relevant character sets, maintenance window and any excluded paths. Keep secrets out of public notes. If restoring to another server requires credentials or encryption keys held elsewhere, document the authorized recovery route without embedding those secrets in the web archive.

Store a separate protected copy and monitor the process

Copy the completed artifacts to storage outside the hosting account and protect access in transit and at rest. A backup reachable only through the same compromised account is a weak recovery boundary. Apply retention that matches the business need and verify that scheduled jobs report failures to an owner.

Provider backups and paid VPS recovery points can complement application exports, but their scope and retention differ. A manual download, an automated website export and a full VPS restore are different recovery tools. Check which service you have purchased and what restoring it will overwrite before relying on it.

Prove the backup by restoring an isolated copy

Restore into a separate directory and a database account that cannot access production. Update the copied application's configuration to use that test database, then disable outbound mail, billing jobs and other live integrations before starting it. Compare expected content and test representative workflows.

• Confirm both database and file archives came from the intended recovery window.
• Check users, uploads, configuration and important application behavior.
• Record restoration time and missing dependencies.
• Keep a recent tested backup available before deleting older copies.

Primary documentation

• MariaDB logical backup reference
• cPanel Backup Wizard
• WP-CLI database export