Bluehost Self-Managed VPS and VDS: How to Schedule and Verify Backups

Regular, automated backups are one of the most important parts of running a Bluehost Self-Managed VPS or Virtual Dedicated Server (VDS). Bluehost doesn't currently offer a backup service for Self-Managed VPS or VDS plans, so backing up your data is your responsibility. This guide shows how to set up scheduled file and database backups (including Docker containers), use safer scripting approaches, and avoid common data-loss and security mistakes.

Notes:

These instructions apply to AlmaLinux 8/9/10, Rocky Linux 8/9/10, CentOS Stream 9/10, Fedora, Ubuntu, and Debian.
For Dockerized apps (WordPress, n8n, LEMP, LAMP, Portainer), see How to Back Up Dockerized Apps for the right backup and database methods.
Run the commands in this guide as root. If you log in as a regular user, run sudo -i first to open a root shell. Output redirection (>) doesn't work with sudo alone.
We recommend verifying your backups by inspecting them, testing them, and, ideally, restoring them.

Why Schedule and Verify Backups?

Automated, scheduled backups help you recover from mistakes, server failures, ransomware, and hacks.
Verification (checking, testing, and restoring backups) helps confirm that you can recover your data when it matters.
Native and Dockerized apps both need their own backup and restore strategies.

Create the Backup Directory

Create your backup directory before you run any backup job. This prevents backup jobs from failing and keeps your backups private. The second command makes the folder accessible only to the root user.

mkdir -p /backups chmod 700 /backups

How to Schedule File and Directory Backups (All Distributions)

Back up a directory:

tar -czvf /backups/www-backup-$(date +%F).tar.gz /var/www/html

Example Output:

/var/www/html/ ... /var/www/html/index.php

Change the path to any data directory you want to back up, such as /etc/ or /home/.

How to Schedule Database Backups (All Distributions)

MySQL and MariaDB (WordPress, LEMP, LAMP, and many other apps):

mysqldump --single-transaction database_name > /backups/db-backup-$(date +%F).sql

The --single-transaction option takes a consistent backup of InnoDB tables without locking them.

Security: Don't put database passwords directly in shell commands or crontabs (for example, with -p'password'). Anyone who can run ps aux on the server can see them. Instead, save your database credentials in a /root/.my.cnf file that only the root user can read.

Create the file with the following contents, replacing the user name and password with your own:

[mysqldump] user=your_db_user password=your_db_password

Then restrict the file so only the root user can read it:

chmod 600 /root/.my.cnf

After that, mysqldump reads the credentials from the file, so you don't need any password options in your commands.

PostgreSQL (apps that use PostgreSQL, such as Odoo):

sudo -i -u postgres pg_dump db_name > /backups/pgdb-backup-$(date +%F).sql

How to Use Cron for Automated Backups and Retention (All Distributions)

Use cron to schedule backups daily, weekly, or on whatever schedule you need.

Edit the root crontab:

crontab -e

Add a daily file backup at 2:00 AM and a daily database backup at 2:05 AM:

0 2 * * * tar -czf /backups/www-backup-$(date +\%F).tar.gz /var/www/html 5 2 * * * mysqldump --single-transaction database_name > /backups/db-backup-$(date +\%F).sql

In a crontab, escape percent signs (%) with a backslash (\%). Otherwise, cron doesn't read the date correctly. The database job reads its credentials from /root/.my.cnf.

Backup rotation (automatic cleanup):

Without a cleanup job, daily backups eventually fill your server's disk. Add this job to your crontab to delete .tar.gz and .sql files in /backups that are older than 30 days. It runs daily at 4:00 AM.

0 4 * * * find /backups/ -type f $ -name "*.tar.gz" -o -name "*.sql" $ -mtime +30 -delete

Warning: If your backup jobs stop working, this cleanup job keeps deleting old backups, and eventually none are left. Check regularly that new backups are being created.

Tip: For complex or multi-step backups, put your commands in a script instead of one long crontab line. Save it as /root/backup.sh, make it executable with chmod +x /root/backup.sh, and have cron run it, for example 0 2 * * * /root/backup.sh.

How to Verify Your Backups

Check a backup archive's contents:

tar -tzvf /backups/www-backup-YYYY-MM-DD.tar.gz

Replace YYYY-MM-DD with the date in your backup's file name.

Example Output:

drwxr-xr-x root/root 0 2026-10-09 02:00 var/www/html/ -rw-r--r-- root/root 3928 2026-10-09 02:00 var/www/html/index.html

Preview a database backup:

head -n 5 /backups/db-backup-YYYY-MM-DD.sql

Example Output:

-- MySQL dump 10.13 Distrib 8.0.32, for Linux (x86_64) ... CREATE TABLE `wp_posts` ( `ID` bigint(20) unsigned NOT NULL auto_increment,

Test restores:

We recommend doing a test restore at least once a month. Restore to an isolated test server or a test database, not your live site, to confirm your backups work.

How to Back Up Dockerized Apps (WordPress, n8n, LEMP, LAMP, Portainer)

Follow these steps if you installed your software with a one-click install that runs in Docker containers with attached volumes.

List your running containers:

docker ps

Example Output:

CONTAINER ID IMAGE NAMES 3c4a2fa9a654 wordpress:... wordpress 53d9cdf733a1 traefik traefik

Some columns are left out of this example.

List your volumes:

docker volume ls

Example Output:

DRIVER VOLUME NAME local wordpress_wpdata local n8n-data local portainer_data

The container and volume names on your server may differ from the examples in this section. Use the names from your own output.

Back up a data volume:

Warning: Backing up a volume while an app is writing to it can produce a corrupted archive. Stop the container first, then start it again when the backup finishes. Your app is offline while the container is stopped.

This example backs up the WordPress data volume:

docker stop wordpress docker run --rm -v wordpress_wpdata:/data -v /backups:/backup busybox tar czf /backup/wordpress-vol-$(date +%F).tar.gz -C /data . docker start wordpress

Back up a database from inside a running Docker container:

If your database runs in a container, a mysqldump or pg_dump command on the server itself won't reach it. Run the command inside the container with docker exec instead.

MySQL and MariaDB containers:

docker exec container_name sh -c 'MYSQL_PWD="$MYSQL_ROOT_PASSWORD" mysqldump --single-transaction -u root database_name' > /backups/docker-db-$(date +%F).sql

Replace container_name and database_name with your own values. Many MySQL and MariaDB containers store the root password in an environment variable such as MYSQL_ROOT_PASSWORD. This command passes that value to mysqldump through the MYSQL_PWD environment variable instead of a -p option, so the password doesn't appear in the command line that ps shows. Check your container's settings for the variable name it uses. If mysqldump isn't found in a MariaDB container, use mariadb-dump instead.

PostgreSQL containers:

docker exec container_name pg_dump -U username database_name > /backups/docker-pgdb-$(date +%F).sql

Replace container_name, username, and database_name with your own values.

Automate Docker backups and cleanup with cron:

Add these lines to your root crontab. The first line stops the container, backs up the volume, and always restarts the container, even if the backup fails.

0 3 * * * docker stop wordpress; docker run --rm -v wordpress_wpdata:/data -v /backups:/backup busybox tar czf /backup/wordpress-vol-$(date +\%F).tar.gz -C /data .; docker start wordpress 5 3 * * * docker exec container_name sh -c 'MYSQL_PWD="$MYSQL_ROOT_PASSWORD" mysqldump --single-transaction -u root database_name' > /backups/docker-db-$(date +\%F).sql 0 4 * * * find /backups/ -type f $ -name "*.tar.gz" -o -name "*.sql" $ -mtime +30 -delete

Tip: Docker backups involve several steps, such as stopping containers, saving data, and checking the results. We recommend putting them in a single script and having cron run that script.

Best Practices

Keep a copy of your backups somewhere other than your server, such as a separate disk, a remote mount, or cloud storage. Backups stored only on your server's main disk can be lost along with the server.
Limit how long you keep backups, using an automated cleanup such as find ... -delete, so your disk doesn't fill up.
Test-restore your backups regularly, for example once a month.
Back up your backup scripts and root crontab too, so you can rebuild your setup quickly after a failure.
Keep passwords out of crontabs and scripts. Store them in files that only the root user can read.

Summary

Scheduling and verifying backups on your Bluehost Self-Managed VPS or Virtual Dedicated Server (VDS) helps you recover your files, apps, and databases if something goes wrong. Create a private backup directory, schedule backups with cron, use the Docker and database steps that match your setup, rotate old backups, and test your restores regularly.

Did you find this article helpful?