WordPress Backup Strategies for Shared Hosting and VPS

Why WordPress Backups Matter on Both Shared Hosting and VPS

If you run WordPress on shared hosting or a VPS, a solid backup and restore strategy is not a luxury – it is basic hygiene. A single broken plugin update, a compromised admin account, or a misconfigured migration can quietly corrupt your database or theme files. Often you do not notice immediately; you just see orders missing from WooCommerce, contact form entries gone, or layout changes that refuse to save. At that moment, the only question that really matters is simple: do you have a recent, clean backup you can restore fast, without guessing or improvising?

In this guide, we will walk through practical WordPress backup strategies that work well on both shared hosting and VPS environments. We will look at what you actually need to back up, how to automate the process with plugins, control panel tools and real cron jobs, and how to test restores so you are not surprised during an incident. All examples are written from the hosting side, drawing on the same playbooks we use when designing backup policies for dchost.com shared hosting, NVMe VPS and dedicated servers.

What a Complete WordPress Backup Really Includes

Before choosing tools or schedules, you need to understand what a complete WordPress backup actually is. Many people think “database backup” is enough, but WordPress stores critical data in two places.

1. The database (MySQL/MariaDB)

Your MySQL or MariaDB database contains:

• All posts, pages and custom post types
• Comments and comment meta
• Users and user roles
• WooCommerce products, orders and customers
• Plugin and theme settings (for many plugins)

Database corruption or an incomplete dump is one of the most painful failure modes, because you lose content and transactional data, not just design.

2. The files (wp-content and core)

Your file system holds:

• wp-content/uploads: all media, product images, documents and theme assets
• wp-content/themes: active and inactive themes, plus any customizations
• wp-content/plugins: plugins and their files
• wp-config.php: database credentials, salts, some performance and security tweaks
• WordPress core files (wp-admin, wp-includes, root files)

For most scenarios, you must be able to restore database + wp-content + wp-config.php. Core files can be reinstalled, but keeping them in your backups speeds up full-site restores and migrations.

In our separate article on the 3‑2‑1 backup strategy and automation on cPanel, Plesk and VPS, we go deeper into why multiple copies and different locations matter. For WordPress specifically, just remember: if your backup does not cover both data and files, it is incomplete.

Backup Strategy Fundamentals: RPO, RTO and 3‑2‑1 for WordPress

Good WordPress backup design starts from two practical questions:

• RPO (Recovery Point Objective): How much data can you afford to lose? For a low‑traffic blog, losing 24 hours of posts might be fine. For an active WooCommerce shop, even one hour of missing orders is painful.
• RTO (Recovery Time Objective): How long can the site be broken or partially broken while you restore? Ten minutes? One hour? Half a day?

Once you have those numbers in mind, align them with the classic 3‑2‑1 backup rule we use across dchost.com environments:

• 3 copies of your data (production + at least two backups)
• 2 different media types (for example: disk on your hosting account + object storage)
• 1 copy offsite (on infrastructure separate from your primary server)

On shared hosting or a single VPS, this translates into:

• At least one local backup (inside the same server/storage, fast to restore)
• At least one remote backup (S3‑compatible storage, another VPS, etc.)
• Automated retention and pruning, so you do not run out of disk space

If you want to design a more formal disaster recovery plan for a busy WordPress or WooCommerce site, have a look at our piece on how to write a no‑drama DR plan with realistic RTO/RPO and backup tests.

Automated WordPress Backups on Shared Hosting

Shared hosting is still the most common home for WordPress sites. The good news: most shared platforms (including ours at dchost.com) give you a control panel like cPanel with built‑in backup tools. The challenge is using them correctly and adding a second layer with WordPress‑level backups.

1. Host‑level backups (cPanel or similar)

Host‑level backups operate outside WordPress. They usually cover:

• All website files under your account (public_html and others)
• All databases attached to the account
• Sometimes email accounts and settings

Typical options in a control panel are:

• Full account backups (for disaster recovery or migrations)
• Home directory backups (files only)
• Individual database backups

On shared hosting, your first layer should be automated daily host‑level backups kept for several days or weeks, depending on your storage plan and risk level. These are ideal when you need to restore an entire account or when multiple sites under the same account are affected.

2. WordPress‑level backups using plugins

Host‑level backups are great, but they are often “all or nothing” and sometimes require opening a ticket to restore. That is why we recommend adding a WordPress‑specific backup plugin as your second layer. The best ones can:

• Back up only the website you care about, not the whole account
• Send backups to remote destinations (S3‑compatible storage, SFTP, WebDAV, etc.)
• Schedule full and database‑only backups independently
• Offer one‑click or guided restore inside wp‑admin

When configuring a backup plugin on shared hosting:

• Avoid storing many backups on the same shared account. Keep 1–2 local copies for quick restores and push older copies offsite.
• Throttle backup performance. Shared hosting has CPU, I/O and memory limits. Configure plugins to use smaller archive chunks and lower concurrency, so backups do not trigger “Resource Limit Reached” errors.
• Split full and database‑only jobs. For a WooCommerce shop, a nightly full backup plus an hourly or every‑2‑hours database backup is a good starting point.

If you have ever hit cPanel resource limits while running heavy tasks like backups or imports, our guide on understanding cPanel resource limits and fixing the ‘Resource Limit Reached’ error is worth a read.

3. Scheduling on shared hosting: wp‑cron vs real cron

On most shared hosting plans, you do not have root access, but you usually have access to the control panel’s cron feature. WordPress has its own pseudo‑cron system called wp‑cron, which triggers only when someone visits the site. This can be unreliable for backups:

• Low‑traffic sites may not run scheduled backups on time
• High‑traffic sites can overload wp‑cron with too many tasks

A better pattern is:

1. Disable wp‑cron from auto‑running on every page load
2. Trigger wp‑cron via real cron in cPanel every 5–15 minutes

We have a detailed walkthrough on this in our article about disabling wp‑cron and using real cron jobs for WordPress on cPanel and VPS. The same approach keeps scheduled backup tasks much more predictable.

Automated WordPress Backups on a VPS

On a VPS, you have far more control – which is both a superpower and a responsibility. You are not limited to what the hosting control panel offers; you can design your own backup stack at the OS level, at the database level, and inside WordPress.

1. Decide who is responsible for backups

First, clarify whether your VPS is managed or unmanaged. On an unmanaged VPS, you are typically responsible for backups unless you explicitly add a backup service. On a managed VPS, providers like us can help design and monitor backup policies with you, but it is still important to understand what is being backed up and how often.

If you are comparing options, our article on managed vs unmanaged VPS hosting and hidden responsibilities goes into the practical trade‑offs.

2. Layers of backup on a VPS

On a VPS, think in layers:

• Application layer (WordPress plugins) – similar to shared hosting, useful for quick per‑site restores and migrations.
• Database layer – scheduled mysqldump or physical backups (e.g. XtraBackup) for MySQL/MariaDB.
• Filesystem layer – tar archives or snapshot‑style backups of /var/www (or wherever your sites live), plus relevant config files (Nginx/Apache, PHP‑FPM, etc.).
• Offsite layer – sync backups to S3‑compatible storage or a remote server using tools like restic, borg or rclone.

We have an in‑depth guide on offsite backups with restic/borg to S3‑compatible storage, including versioning and encryption, which pairs very well with WordPress sites running on a VPS.

3. Example: Simple backup scheme for a single WordPress on a VPS

Here is a practical baseline setup we often recommend for a single production WordPress site on a VPS:

• Every night:
  • Run mysqldump (or a similar tool) to back up the WordPress database
  • Create a compressed archive (e.g. tar.gz) of the site’s directory (files + wp-config.php)
  • Store at least 7–14 days of these backups locally on the VPS
• Every night or every few hours:
  • Sync the latest local backups to an S3‑compatible bucket or remote server
  • Enforce retention at the remote side (for example, 30–90 days)
• Every hour (for busy shops):
  • Run a database‑only backup for more granular recovery of orders and user actions

All of this is controlled with cron jobs on the VPS. Combine it with a WordPress plugin that can restore from a local or remote backup if you prefer a point‑and‑click restore experience.

4. Containers and Docker‑based WordPress

If you are running WordPress in Docker on a VPS, do not forget that container images are not backups. You still need to back up:

• The database volume (MySQL/MariaDB data directory)
• The WordPress files volume (wp‑content and config)

We cover this in much more detail in our guide to running WordPress on Docker Compose with persistent volumes and auto‑backups. The same principles apply whether your Docker stack lives on a dchost.com VPS or a dedicated server.

Designing Backup Schedules That Match Your Site

There is no single “right” schedule, but there are patterns that work well. Start from how dynamic your site is:

1. Low‑change brochure or blog site

• Full backups: once per day or every 2–3 days
• Database‑only backups: once per day
• Retention: 7–14 days locally, 30+ days offsite

This is often enough if you publish content a few times per week and do not accept orders or user‑generated content.

2. Active WooCommerce or membership site

• Database‑only backups: every 15–60 minutes (depending on order volume)
• Full backups (files + DB): once per day
• Retention: at least 7–14 days locally, 30–90 days offsite

Here, your RPO is stricter: you want to be able to restore with minimal lost orders. Frequent database backups (or, more advanced, database binlog/WAL archiving) are the key.

3. Multi‑site WordPress installations

With WordPress Multisite, a single database and codebase serve many sites. That means a failure impacts more properties at once.

• Full backups: daily, with a longer offsite retention
• Database‑only backups: at least hourly for active networks
• Testing: regular restores to a staging environment, because network‑wide plugins and custom domain mapping can complicate restores

If you are running Multisite on a VPS or considering it, our article on WordPress Multisite on a VPS with domain mapping and SSL dives into the hosting‑side considerations, many of which impact your backup and restore strategy as well.

How to Restore WordPress Safely from Backups

Backups are only as good as your ability to restore them quickly, correctly and calmly. The biggest mistake we see is people testing backups only when something is already broken. Build a simple restore playbook now, then rehearse it.

1. Types of restore scenarios

Think in terms of scenarios, each with its own restore procedure:

• Theme/plugin breakage after an update: Restore only files (theme, plugin, sometimes uploads) while keeping the latest database.
• Content or order loss: Restore database from a point in time close to the incident, sometimes combined with file restores.
• Full compromise or ransomware on the site: Restore both database and files from a clean backup, rotate all passwords, review logs and harden security.
• Accidental deletion of the hosting account or VPS: Restore from provider snapshots plus your own offsite backups.

2. Restoring from a WordPress plugin

Most backup plugins offer a one‑click or step‑by‑step restore process:

1. Upload or select the backup archive (local or remote).
2. Choose whether to restore files, database or both.
3. Run the restore and wait for completion.
4. Clear caches (plugin, server‑side, CDN) and verify the site.

Best practice is to first restore to a staging copy of your site (on a subdomain or separate VPS) to verify the backup is clean and compatible with your current PHP/MySQL versions. Only then apply the same backup to production.

3. Restoring from cPanel or host‑level backups

On shared hosting, provider‑level backups can usually be restored via:

• Control panel interface: select a date and restore files, databases or full account.
• Support ticket: ask the team to restore specific items.

Because host‑level restores are coarse‑grained, document in your runbook when to prefer them. For example, if multiple WordPress sites under the same account are corrupted by malware, a full home directory + all databases restore from a known‑good date might be faster than trying to clean each site manually.

4. Restoring on a VPS with manual tools

On a VPS, you will often restore using SSH and CLI tools:

1. Disable web access temporarily (maintenance page, firewall rule, or web server stop).
2. Restore the database: drop and recreate the database, then import your mysqldump or equivalent.
3. Restore files: extract your tar archive into the web root, preserving permissions and ownership.
4. Flush object caches (Redis/Memcached) and opcode cache if used.
5. Re‑enable access and test.

If your WordPress uses a CDN or full‑page caching proxy (Nginx, Varnish, LiteSpeed Cache, etc.), remember to clear or invalidate those layers as part of your restore runbook. Otherwise you may be looking at stale content and thinking the restore failed.

Testing and Documenting Your WordPress Backup Strategy

A backup strategy is not “done” when automation is set up. It is done when you have tested restores and written down the steps so anyone on your team can execute them.

1. Run regular restore drills

At least a few times per year, run a realistic exercise:

• Pick a recent backup (not the latest one only).
• Restore it to a staging environment (separate subdomain, staging VPS, or local dev stack).
• Verify:
• Admin login works
• Recent posts/pages are present
• WooCommerce orders and customer data look correct (where applicable)
• Contact forms, search and key flows behave as expected

Time how long this takes from “we need to restore” to “site is back”. Compare that with your RTO target and adjust processes if needed.

2. Write a simple runbook

Your runbook can be a shared document or wiki page. It should include:

• Where backups are stored (local path, remote URLs, credentials location)
• Which tools/plugins are used for backups and restores
• Step‑by‑step instructions for the three main scenarios: plugin/theme failure, data loss, full compromise
• How to verify success (checklist of pages, flows, logs)
• Who is responsible and how to escalate if something goes wrong

If you want templates and examples, our article on writing a DR plan with practical runbook templates is written exactly with these situations in mind.

Where dchost.com Fits Into Your WordPress Backup Plan

At dchost.com, we look at backups as part of the hosting architecture, not an afterthought. On our shared hosting platforms, we provide automated, provider‑level backups as a baseline, and then help customers layer WordPress‑level backups on top for faster, more granular restores. On our NVMe VPS and dedicated servers, teams often combine scheduled database and filesystem backups with encrypted offsite sync to S3‑compatible storage or a second VPS, following the same 3‑2‑1 patterns we have covered here.

Whether you are starting with a small WordPress site on shared hosting or consolidating multiple high‑traffic sites onto a VPS or dedicated server, the goal is the same: predictable, automated backups and restores you have already rehearsed. If you would like help designing or reviewing your backup strategy on dchost.com infrastructure, our team is happy to walk through your current setup, your RPO/RTO targets and your growth plans, and suggest a calm, no‑drama backup and disaster‑recovery roadmap tailored to your WordPress stack.