How to Back Up Your Website Automatically for Free
Every site owner believes they have backups until the day they need one and discover the last copy is eight months old, stored on the same server that just failed, or missing the database entirely. A website backup is a complete, restorable copy of everything your site needs to run, which means its files, its database, and its configuration, stored somewhere independent of the live server. Doing this manually never lasts, so this guide shows how to automate backups for free on the most common setups and, just as importantly, how to prove they restore.
Quick Answer: To back up a website automatically for free, schedule a job that copies both site files and a database dump, using a plugin like UpdraftPlus for WordPress or a cron script with mysqldump and rclone for custom sites. Send copies to off-server storage such as Google Drive or Backblaze B2, keep several versions, and test a restore regularly.
What a Complete Website Backup Includes
A complete website backup includes three things: the files, the database, and the configuration that ties them together. Missing any one of them turns a restore into a rebuild.
Files are your code, themes, plugins, uploaded images, and documents. On WordPress, the uploads folder is often the largest and most irreplaceable part. The database holds content, users, orders, and settings. A file-only backup of a dynamic site is nearly useless, because the posts and accounts live in the database. Configuration covers environment variables, web server settings, cron jobs, and DNS records, which are often forgotten because they live outside the project folder.
Who is responsible for each layer depends on your hosting model. On shared hosting, the provider may keep server backups, but terms rarely guarantee them for your use; on a VPS, everything is on you. This breakdown of shared hosting versus VPS backup responsibilities helps you see where the gaps are on your plan.
Two terms guide every decision. Recovery point objective is how much data you can afford to lose, which sets backup frequency. Recovery time objective is how long you can be offline, which sets how simple your restore process must be. A blog updated weekly can live with weekly backups; a shop taking daily orders cannot.
The 3-2-1 Rule Adapted for Small Websites
The 3-2-1 rule is a long-standing backup principle, also referenced in guidance from the US Cybersecurity and Infrastructure Security Agency: keep three copies of your data, on two different types of storage, with one copy off-site. Here is how it translates to a small website.
- Copy one: the live site. Your production server counts as one copy, but never as a backup on its own.
- Copy two: a scheduled off-server backup. Automated daily or weekly backups sent to a cloud storage service such as Google Drive, Dropbox, Backblaze B2, or an S3-compatible bucket.
- Copy three: an independent second destination. A periodic download to your computer or a second cloud provider, so a single compromised account cannot erase everything.
- Two storage types: The server disk and cloud object storage count as different media for practical purposes.
- One off-site copy: At least one copy must live with a different company than your host, so an account suspension or provider outage cannot take your backups with it.
- Versioning: Keep multiple dated versions. If malware infects the site and goes unnoticed for weeks, only an older backup is clean.
Encryption belongs on top of these rules. Backups contain password hashes, customer emails, and API keys, so encrypt them before they leave the server whenever your tool allows it.
Free Backup Methods Compared
Several free methods can automate backups, and the right one depends mostly on how your site is built. The table compares the most practical options.
| Method | Best For | Backs Up Database? | Main Limitation |
|---|---|---|---|
| UpdraftPlus (free version) | WordPress sites | Yes | Some destinations and incremental backups require the paid version |
| Hosting control panel backups | Shared hosting accounts | Usually | Often stored on the same provider; retention varies by plan |
| Cron + mysqldump + rclone | Custom PHP or Node.js sites on a VPS | Yes | Requires shell access and basic scripting |
| restic or BorgBackup | Servers needing encrypted, deduplicated history | Yes, via a dump step | Steeper learning curve |
| Git plus GitHub Actions | Static sites and code | Only if you script an export | Not suitable for large media or private data in public repos |
For static sites, your Git repository already is the backup of your code, as long as it lives on a remote such as GitHub and on your machine. For anything with a database or user uploads, you need a scheduled job.
Why Untested Backups Fail: A Practitioner's View
A backup you have never restored is a hope, not a backup. This section is practitioner analysis from recovering small sites after failures, hacks, and accidental deletions.
The failures I see most often are not dramatic. A backup job ran for months but silently stopped when a storage token expired. A database dump completed but was empty because the database user lacked permissions. A backup archive excluded the uploads folder to save space, so the restored site had every post and no images. In each case, the owner found out only during an emergency.
Database dumps deserve particular care. For MySQL with InnoDB tables, mysqldump --single-transaction creates a consistent snapshot without locking the site. Understanding how your site connects to its database, covered in this guide to a PHP and MySQL database connection, also tells you exactly which credentials and database names your backup script needs.
The fix is a restore drill. Every month or quarter, take the latest backup, restore it to a local machine or a staging subdomain, and click through the site. Time how long it takes. That number is your real recovery time, and the drill catches broken backups while they are still harmless.
Common Backup Mistakes and How to Avoid Them
Most backup disasters trace back to a few avoidable habits. Review your setup against this list today.
- Storing backups on the same server. If the server fails or is compromised, the backups go with it. Always send a copy elsewhere.
- Backing up files but not the database. Dynamic sites store most content in the database. Include a fresh dump in every backup.
- Keeping only one version. Overwriting a single backup means an infected or corrupted site overwrites your only clean copy. Keep daily, weekly, and monthly versions.
- Using your main account credentials for backup storage. Create a dedicated storage key with access only to the backup bucket, so a leaked key cannot touch anything else.
- Leaving backups publicly accessible. Never store archives in a web-accessible folder, where anyone who guesses the file name can download your database.
- Ignoring failure notifications. Configure email alerts for failed jobs, and occasionally check that successful-run notices are still arriving.
- Forgetting scheduled job expiry. GitHub disables scheduled workflows in public repositories after 60 days without repository activity, which can quietly stop Actions-based backups.
- Never testing a restore. Schedule restore drills just like backups.
Walkthrough: Free Automated Backups for a Custom Site on a VPS
This walkthrough sets up nightly encrypted backups of files and a MySQL database to free-tier cloud storage using cron and rclone. It assumes a Linux server with shell access.
Step 1: Choose off-site storage. Create a free account with a provider that offers a no-cost storage allowance, such as Google Drive or Backblaze B2. Create a dedicated bucket or folder and a restricted access key.
Step 2: Install and configure rclone. Install rclone from its official site, run rclone config, and add your storage as a remote. Then add a crypt remote on top of it so files are encrypted before upload.
Step 3: Create a database credentials file. Store MySQL credentials in a protected option file, such as ~/.my.cnf with permissions set to 600, so passwords never appear in scripts or process lists.
Step 4: Write the backup script. The script should dump the database, archive the site files, upload both, and clean up old local copies:
#!/bin/bash
set -euo pipefail
STAMP=$(date +%F)
mysqldump --single-transaction site_db | gzip > /backups/db-$STAMP.sql.gz
tar -czf /backups/files-$STAMP.tar.gz -C /var/www site
rclone copy /backups secret-backups:site --max-age 25h
find /backups -type f -mtime +3 -deleteStep 5: Schedule it with cron. Run crontab -e and add a line such as 30 2 * * * /usr/local/bin/site-backup.sh >> /var/log/site-backup.log 2>&1 to run nightly at 2:30 a.m. server time.
Step 6: Add retention on the remote. Use your storage provider's lifecycle rules, or an rclone cleanup command, to keep recent daily backups plus a few weekly and monthly ones.
Step 7: Add alerts. Pair the job with a free cron monitoring service that expects a ping after each successful run and emails you when one is missed.
Step 8: Run a restore drill. Download the latest archive through the crypt remote, import the dump into a test database, extract the files to a staging directory, and confirm the site loads with recent content and images.
For WordPress on shared hosting, the equivalent takes minutes: install UpdraftPlus, connect Google Drive or Dropbox, set separate schedules for files and database, choose how many versions to retain, and run one manual backup to confirm the connection.
Key Takeaways
- A complete website backup includes files, the database, and configuration; missing any of them turns a restore into a rebuild.
- The 3-2-1 rule means three copies, two storage types, and at least one copy stored with a different provider than your host.
- Free tools such as UpdraftPlus, cron with mysqldump and rclone, and restic can fully automate backups for most small sites.
- Multiple dated versions are essential, because malware or corruption can go unnoticed long enough to infect recent backups.
- Only a tested restore proves a backup works, so schedule restore drills as seriously as the backups themselves.
Frequently Asked Questions
How often should I back up my website?
Back up as often as your content changes and as much as you can afford to lose. A rarely updated brochure site may need weekly backups, while a store or membership site taking daily orders needs at least daily database backups. Files and databases can follow separate schedules.
Are my web host's backups enough?
Host backups are a useful extra layer, but they should not be your only one. They are often stored with the same provider, retention varies, and terms may not guarantee them. If your account is suspended or the provider has an outage, you need an independent off-site copy you control.
What is the best free backup plugin for WordPress?
UpdraftPlus is one of the most widely used free WordPress backup plugins, offering scheduled backups of files and database to destinations such as Google Drive, Dropbox, and Amazon S3. Whichever plugin you choose, confirm it backs up the database and uploads folder, and test a restore.
Where should I store website backups for free?
Store backups with a provider separate from your host, such as Google Drive, Dropbox, or object storage like Backblaze B2, which offers a small free allowance. Use a dedicated account or restricted access key, encrypt backups before upload when possible, and keep a periodic copy on your own computer.
How do I back up a MySQL database automatically?
Schedule mysqldump with cron, using the --single-transaction option for InnoDB tables, compress the output, and upload it off-server with a tool like rclone. Store credentials in a protected option file rather than in the script, and monitor the job so failed runs trigger an alert.
How do I know my backups actually work?
The only reliable proof is restoring one. Regularly restore the latest backup to a local or staging environment, import the database, and browse the site to confirm recent content and images are present. Also check that backup file sizes are reasonable, since empty archives are a common silent failure.
Conclusion
The most important decision about backups is treating restore as the real goal: automation, off-site storage, and multiple versions only matter if you can bring the site back quickly and completely. Set up a scheduled job today, send copies to independent storage, and run your first restore drill this week. With recovery covered, round out your site's protection with this free SSL certificate setup so data is secure in transit as well as at rest.
