Before you start
- WordPress admin access, or SSH and access to cron jobs
- Somewhere off the server to keep copies — cloud storage you control
Step 1: Know what your host already keeps
Every Serverlys plan includes daily server-level backups. Before relying on any host's backups, find out how many days they go back, because a problem noticed after that window cannot be rolled back.
Step 2: Keep a second copy somewhere else
A backup that lives only on the same server or account is lost with it. The common rule is three copies, on two kinds of storage, with one off-site. For a small site, that means the host's backups plus a scheduled copy in cloud storage you own.
Step 3: Schedule it with a plugin
A backup plugin such as UpdraftPlus can run on a schedule and send copies to remote storage — Google Drive, Dropbox or Amazon S3, among others. Set files and database separately: the database changes every time someone orders or comments, the files mostly when you update something. Choose how many copies to retain so storage does not fill up.
Step 4: Or schedule it with cron
On cPanel, Advanced → Cron Jobs runs a command on a schedule. This exports the database nightly at 03:00 and deletes copies older than 14 days. In crontab every % must be escaped as \%. The path to wp can differ from server to server — run `which wp` over SSH to find yours. Keep the folder outside public_html so it cannot be downloaded.
0 3 * * * cd ~/public_html && wp db export ~/backups/db-$(date +\%F).sql 30 3 * * * find ~/backups -name 'db-*.sql' -mtime +14 -deleteStep 5: Back up more often if the database is busy
A store or a membership site can lose a day of orders or sign-ups to a daily schedule. Run database backups several times a day there; files can stay daily.
Step 6: Test a restore
Restore the latest copy onto a staging subdomain and log in. A backup that has never been restored is an assumption, and the time to find a missing table or a corrupt archive is now.
The mistake people make
Keeping backups only on the same server, or inside public_html. A server failure or a hacked account takes the backups with it — and an archive in public_html can be downloaded by anyone who guesses its name, database passwords included.