I have run websites on shared hosting for years, and I have lost count of how many times a working backup saved me. A single bad plugin update, a hacked theme, or a neighbor hogging CPU can knock your site offline without warning. That is why finding the best backup solution for shared hosting is not optional – it is the difference between a 20-minute recovery and a multi-day disaster.
In this guide, I will walk you through everything that actually works when SSH is locked down, exec() is disabled, and your host’s cron is throttled. We will cover host-native backups, WordPress plugins, manual phpMyAdmin + FTP workflows, automated off-site backups to S3 and Google Drive, the 3-2-1 rule, restore verification, and the retention sweet spot most guides skip. By the end, you will have a layered backup plan you can set up today, even on a $3/month shared plan.
Table of Contents
What Is the Best Backup Solution for Shared Hosting?
The best backup solution for shared hosting is a layered combination of three methods: host-provided backups (cPanel, JetBackup, CodeGuard), a WordPress or PHP backup plugin (UpdraftPlus, BlogVault, BackupBuddy), and manual exports via phpMyAdmin and FTP/SFTP. No single method on its own is enough – host backups sit in the same datacenter, plugins can fail mid-run on shared resources, and manual exports only protect you if you remember to do them. The strongest shared hosting backup plans automate plugin-based scheduled backups to off-site storage, keep host-native snapshots as a fallback, and store a quarterly phpMyAdmin + files export in a separate location as the last line of defense.
What makes shared hosting different from managed or VPS hosting is that you do not get root access, SSH, or reliable cron. That means tools like rsync, mysqldump on the command line, and Bash automation are off the table. Your backup solution has to run through your control panel, a PHP script, or a plugin’s scheduler. I will show you exactly which combinations survive these constraints – and which popular tools silently fail when the host throttles them.
Shared Hosting Constraints You Must Work Around
Before you pick a backup tool, you need to understand the box you are working in. Shared hosting is cheap for a reason: hundreds of accounts share one server, one OS, and one set of resources. Your host protects that shared environment with strict guardrails, and most of them affect backups directly.
No SSH access. Most entry-level shared hosting plans disable SSH entirely. Even when SSH is enabled, it usually arrives as a jailed shell without rsync, tar, or mysqldump. Anything that depends on command-line tools is dead on arrival.
exec() and shell_exec() are disabled. PHP functions that spawn processes are blocked for security. This kills backup plugins that try to call mysqldump or zip via the shell. The plugin has to do everything in pure PHP, which is slower and more memory-hungry.
Cron job limits. Shared hosts typically cap you at 5 to 15 cron entries, and the minimum interval is often 5 or 15 minutes. Some hosts throttle cron further during peak hours. Heavy backup jobs scheduled via cron may simply not run when they should.
PHP memory limits. The default PHP memory_limit on shared hosting is often 128M or 256M. A large MySQL database export (over 100 MB) or a full site backup can blow past that limit and the script dies mid-zip, leaving you with a corrupt archive.
Inode limits. Every file – including tiny backup chunks – counts against your inode quota. If you keep 30 daily backups and each generates hundreds of small files, you can hit your inode cap and trigger the host to flag your account.
Fair use and CPU throttling. If your backup script pegs the CPU, the host will throttle or kill it. Some hosts explicitly forbid “server-intensive” cron jobs. The result is that backups quietly stop running.
Every solution below is rated against these six constraints. If a tool needs SSH, exec(), or unlimited cron, I will flag it and steer you to a working alternative.
Backup Types Explained: Full vs Incremental vs Differential
Before comparing tools, you need to know what kind of backup each one produces. The three types matter on shared hosting because storage, CPU, and bandwidth all come at a premium.
Full backup. A complete copy of every file and every database row, every time. Simple, easy to restore, but heavy on disk space and CPU. A 5 GB site backed up daily means 35 GB per week of raw archives before compression. On shared hosting, full backups are the default but they are the slowest option.
Incremental backup. After the first full backup, only files that changed since the last backup (full or incremental) are saved. A site that changes 200 MB per day produces 200 MB of incremental data instead of another 5 GB full copy. Restoration is slower because the tool has to replay every incremental in order, but daily storage stays tiny.
Differential backup. A middle ground. After the first full backup, each differential saves everything that changed since that last full backup. Day 2 has one day of changes; day 7 has six days of changes. Restore is faster than incremental (you need the full + the latest differential) but storage grows daily until the next full.
On shared hosting, incremental backups are usually the best fit when available, because they keep CPU and inode usage low. BlogVault and Jetpack Backup both offer true incremental backups. UpdraftPlus and most host-native tools default to full backups unless you specifically configure incremental mode. We will dig into the practical trade-offs here.
Host-Provided Backups: cPanel, JetBackup, and CodeGuard
Every shared host offers some form of backup. The question is whether it is automatic, restorable on demand, and stored separately from your live data. Here is what to look for in each major flavor.
cPanel Backup Wizard
The cPanel Backup Wizard generates a downloadable archive containing your home directory, MySQL databases, and email forwarders. You can pull a full backup, restore a full backup from a file you upload, or run partial backups of just files or just databases. Most hosts enable this by default, but they only guarantee the backups exist – not that they are stored off-server. If the datacenter burns down, your cPanel backup is gone too.
cPanel also exposes JetBackup on newer installations. JetBackup adds scheduled snapshots (daily, weekly, monthly), point-in-time restore, and a self-service restore button in your control panel. Hosts like SiteGround, Bluehost, and Hostinger expose JetBackup to end users. It is the single biggest upgrade to shared hosting backups in the last five years.
CodeGuard
Some hosts bundle CodeGuard as a paid add-on. CodeGuard runs daily automated backups of your files and database, stores them on Amazon S3 (off-site by default), and gives you a one-click restore and a monitoring dashboard. It is the closest thing to a managed backup on a shared plan. The trade-off is cost: CodeGuard is a recurring line item even on a cheap shared plan.
My honest take: rely on your host’s backup as your third layer, not your first. Host backups fail. They get corrupted. They get overwritten too quickly. Reddit threads in r/Wordpress are full of users whose host backup was missing the database, or took three days to restore. Off-site is the only way to sleep well.
WordPress Backup Plugins That Work on Shared Hosting
For WordPress sites, a plugin is the most practical scheduled backup layer because it runs in PHP, respects your memory limit, and pushes directly to off-site storage. Not all plugins survive shared hosting. Here are the ones that do, in my experience.
UpdraftPlus
UpdraftPlus is the most installed WordPress backup plugin, with over 3 million active installs. The free version supports scheduled backups to Amazon S3, Google Drive, Dropbox, Backblaze B2, and more. The premium version adds incremental backups, database-only backups, and pre-update snapshots. On shared hosting, UpdraftPlus handles large databases well because it splits the archive into chunks rather than trying to hold everything in memory at once. If I had to pick one plugin for a single WordPress site on shared hosting, this is it.
BlogVault
BlogVault is a premium service with an off-site backup architecture purpose-built for shared hosting. Backups run on BlogVault’s own servers, not on your host, so PHP memory limits and CPU throttling never block them. It offers true incremental backups, one-click restore to a staging environment, and 90-day retention. The cost is higher than UpdraftPlus, but the reliability is meaningfully better when your host is unreliable.
BackupBuddy
BackupBuddy was the original WordPress premium backup plugin. It still works on shared hosting, ships with its own import tool (BackupBuddy Stash), and supports off-site destinations like Amazon S3, Google Drive, and FTP. The product has slowed in development in recent years, but for a single-site license on a tight budget it remains a credible option.
Jetpack Backup
Jetpack Backup (formerly VaultPress) gives you real-time incremental backups synced to Automattic’s cloud, with 30-day activity log and one-click restore. The trade-off is price – it is the most expensive option per site, and on r/Wordpress the recurring complaint is that it costs more than the hosting itself. For a single critical business site, I think it is worth it. For a portfolio of small sites, the math stops working.
Why ManageWP and MainWP Often Fail on Shared Hosting
I want to flag this because Reddit threads in r/webdev and r/selfhosted keep bringing it up. ManageWP and MainWP are dashboard tools that back up many sites from one console. On paper they look ideal. In practice, they run the backup job on your shared server, hit PHP memory limits on large databases, and time out mid-export. Multiple Reddit users have reported silent failures where ManageWP showed “backup successful” but the archive was empty or missing the wp_options table. If you manage one or two sites, use a per-site plugin. If you manage ten, switch to a VPS.
How to Back Up Manually with phpMyAdmin and FTP
This is the workflow I personally use as a baseline, and it is the one most guides skip. Manual backup through phpMyAdmin and FTP works on literally every shared hosting account, including the cheapest plans with no cron, no SSH, and no plugin permissions. Let me walk you through it.
Step 1: Export the MySQL database with phpMyAdmin
Open phpMyAdmin from your control panel. Select your WordPress (or PHP app) database from the left sidebar. Click the Export tab. For most databases under 50 MB, choose Quick export with SQL format. For larger databases, choose Custom and tick “Save output to a file” plus compression (gzipped). Click Go. Your browser downloads a .sql or .sql.gz file.
If your database is over 100 MB and phpMyAdmin times out, switch to Custom export, drop the maximum length per row to a smaller value, and split the export by table. Most shared phpMyAdmin panels let you check “Export tables individually” which creates one file per table. You will have to import them individually later, but it works where a single dump fails.
Step 2: Download your files via FTP or SFTP
Open FileZilla (or any FTP client). Connect using the FTP credentials from your control panel – usually shown as FTP Accounts or SFTP/SSH Access. Navigate to your site’s root directory (commonly public_html). Drag the entire folder to your local machine. This includes wp-content, wp-config.php, .htaccess, and any non-WordPress PHP files.
For large sites, do it in chunks: wp-content/uploads first (usually the bulk of the size), then plugins, then themes, then the root config files. SFTP is preferred over FTP because the data is encrypted in transit. Most shared hosts give you SFTP on the same port as FTP.
Step 3: Compress and label
Rename your files clearly: site-backup-2026-09-12-files.zip and site-backup-2026-09-12-db.sql.gz. Future-you will thank present-you when you are staring at a folder of mystery .sql files trying to find the right one.
Step 4: Push to off-site storage
Upload both archives to your off-site destination – Google Drive, Dropbox, Backblaze B2, or an external hard drive. Never leave the only copy on the same shared server you are backing up.
Step 5: Restore from a manual backup
Restoration is the reverse. Upload your wp-content folder and root files via FTP back to public_html. Open phpMyAdmin, select the database, click Import, and upload your .sql.gz file. If phpMyAdmin rejects a large import, split the .sql file with a tool like SQL Dump Splitter and import the pieces. Edit wp-config.php if your database name, user, or password changed.
This workflow is slow. It is also the only one that works on every shared host with zero risk of plugin failure. Run it monthly as your belt-and-suspenders layer.
Automated Off-Site Backups Without SSH (S3, Google Drive, Dropbox)
Once your manual workflow is in place, the next step is automation. You want backups running daily without you remembering to do them. Here is how to push to remote cloud storage when you do not have SSH.
Option 1: Plugin schedulers with built-in cloud destinations
UpdraftPlus and BlogVault both connect directly to Amazon S3, Google Drive, Dropbox, and Backblaze B2 from inside the plugin. Configure the destination once, set a schedule (daily for active sites, weekly for static ones), and forget about it. The plugin uploads to off-site storage over HTTPS, which works on every shared host without needing SSH or special ports.
For the cheapest off-site storage, Backblaze B2 is the clear winner. Storage is roughly one-fifth the cost of Amazon S3, the API is S3-compatible, and UpdraftPlus supports it natively. A 50 GB monthly backup archive costs pennies.
Option 2: cPanel cron + curl to a remote endpoint
If you have cron access (most shared hosts allow at least one cron job), you can trigger a remote backup script via curl or wget. The pattern is: a small PHP script on your host packages the latest backup, then POSTs it to a remote endpoint that accepts the file (a Slack webhook with file upload, a Dropbox API endpoint, or your own VPS). This is more advanced but it works without a plugin.
Be careful with cron on shared hosting. A daily backup at 3 AM is usually fine. A cron job that runs every hour will get your account flagged for CPU abuse. Keep it daily or less frequent.
Option 3: External SaaS that pulls from your site
CodeGuard and BlogVault work this way. They run the backup job on their own infrastructure, talking to your site only briefly to fetch the latest data. Your shared host never feels the load. This is the most reliable option when you can afford it.
Whichever route you pick, the rule is the same: at least one full copy must live outside your hosting provider’s datacenter. Same-server backups are not real backups.
The 3-2-1 Backup Rule Applied to Shared Hosting
The 3-2-1 backup rule is simple: keep 3 copies of your data, on 2 different types of media, with 1 stored off-site. It was designed for enterprise IT, but it applies to a $5/month shared hosting account more than most people realize.
Here is how 3-2-1 maps to shared hosting in practice.
3 copies. Live site on the shared server, a recent host-native backup snapshot, and at least one off-site backup in cloud storage or on your laptop. Three independent copies. If two fail, you still have one to restore from.
2 different types of media. The shared server is one type (disk on the host’s storage array). Cloud storage (Backblaze B2, Google Drive) is the second type. A local external hard drive counts as a third type. The point is that you do not put all copies on the same disk array.
1 off-site. At minimum one copy must be physically outside the datacenter. Backblaze B2 and Amazon S3 are off-site by definition. A copy on your laptop is off-site if your laptop is at home. A copy on the same host’s secondary drive is not off-site.
For most shared hosting sites this means: UpdraftPlus daily to Backblaze B2 (off-site cloud), JetBackup weekly snapshot on the host (different media, same datacenter), and a manual monthly phpMyAdmin + FTP download to your laptop (off-site, different media). That satisfies 3-2-1 comfortably.
Restore Testing: How to Verify Your Backups Actually Work
An untested backup is a wish, not a backup. I have seen production sites “with daily backups” lose everything because the backup archive was empty, the database was missing the wp_users table, or the restore silently failed on a corrupt zip. Restore testing is the step almost every guide skips. Here is how to do it.
Build a test environment
Create a subdomain like staging.yoursite.com. In cPanel, add the subdomain, point it to a new folder, and create a fresh empty MySQL database. Do not test on your live site. Ever.
Restore the database
Open phpMyAdmin on the staging database. Click Import, upload your latest .sql.gz file. Confirm every table imports without error. Spot-check wp_options (or your app’s equivalent settings table) for the site URL – if it still points to the live domain, change it to staging.
Restore the files
Upload your backup archive to the staging folder via FTP. Extract it. Edit wp-config.php (or equivalent) to point to the staging database credentials. Visit staging.yoursite.com. You should see a working copy of your site.
Test the critical paths
Log into the staging admin. Create a test post. Submit a test form. Run a test checkout if you run ecommerce. If any of these break, your backup is incomplete – figure out which directory or table is missing before you trust it.
When to run restore drills
Quarterly is the right cadence for most shared hosting sites. Mark it on your calendar. A backup that has not been restored in 90 days is a backup you do not actually have.
Backup Retention Best Practices (14-30 Day Rolling Window)
How long should you keep backups? Long enough to recover from anything you can imagine, short enough to keep storage and cost under control. For shared hosting, 14 to 30 days of rolling backups is the sweet spot.
Daily backups with 30-day retention means you can roll back to any day in the last month. That covers almost every real disaster: a hack discovered weeks after the fact, a bad plugin update that took a week to break, a hosting migration gone wrong. Going beyond 30 days rarely helps unless you have a compliance requirement (PCI-DSS wants 90 days, HIPAA wants longer). If you do, store monthly snapshots for a year, but keep your daily window at 30.
Watch your storage cost. Backblaze B2 charges roughly a fraction of a cent per GB-month, so even 100 GB of monthly archives costs very little. Amazon S3 Glacier is cheaper for cold storage but slower to restore – useful for compliance archives, not for your daily backup set.
Under GDPR, your backup retention period should match your stated data retention policy. If you tell users you delete their data after 30 days, but you keep their data in a backup for two years, you have a compliance gap. Document your retention window and stick to it.
phpMyAdmin vs Plugin vs Host-Native Backup Compared
Here is how the three backup tiers stack up across the dimensions that matter on shared hosting.
| Dimension | phpMyAdmin + FTP (Manual) | WordPress Plugin (UpdraftPlus) | Host-Native (cPanel / JetBackup / CodeGuard) |
|---|---|---|---|
| Ease of use | Moderate – requires steps | Easy – install and configure | Easy – already in your control panel |
| Automation | None – you run it manually | Daily or weekly on a schedule | Daily or weekly (host-dependent) |
| Off-site by default | Only if you upload manually | Yes – to S3, Drive, Dropbox, B2 | Rarely – usually same datacenter |
| Restore speed | Slow – manual re-upload | Fast – one-click restore | Fast – one-click in control panel |
| Cost | Free | Free tier available; premium for incremental | Often bundled; CodeGuard costs extra |
| PHP memory requirements | None – phpMyAdmin handles it | Moderate to high – may need chunked exports | None – runs on host infrastructure |
| Reliability on shared hosting | High – works everywhere | Medium – large DBs may fail | Medium – host throttling and partial restores reported |
The honest answer: pick a plugin for daily automation, host-native for a free weekly fallback, and phpMyAdmin + FTP as your quarterly belt-and-suspenders. That is the three-layer plan that survives real shared hosting failures.
Frequently Asked Questions
What is a backup solution for shared hosting?
A backup solution for shared hosting is a combination of methods that protect your website files and MySQL database without requiring SSH or root access. It usually includes host-provided backups (cPanel, JetBackup, CodeGuard), a WordPress or PHP backup plugin that automates off-site uploads, and manual phpMyAdmin + FTP exports as a fallback layer.
Why is backup important for my website?
Shared hosting puts your site on a server with hundreds of others. A bad neighbor, a hacked theme, a failed plugin update, or a host-side failure can take your site offline or wipe your data. Without a recent off-site backup, recovery can take days – or be impossible. A working backup is the only reliable insurance for your site.
How often should my website be backed up?
Daily is the right cadence for active sites – blogs, ecommerce, SaaS apps, anything with frequent content changes. Weekly is the minimum for static sites, portfolios, or brochure pages that rarely change. Most managed shared hosting plans offer daily snapshots, and plugins like UpdraftPlus can schedule daily automated backups to off-site storage.
Where are my backups stored?
Host-provided backups usually live on the same datacenter as your live site, which is risky if the datacenter has an outage. The safest practice is to push backups to off-site cloud storage – Amazon S3, Backblaze B2, Google Drive, or Dropbox – so a copy exists somewhere physically separate from your shared server.
Can I automate the backup process on shared hosting?
Yes. WordPress backup plugins like UpdraftPlus, BlogVault, and BackupBuddy can run scheduled backups that upload automatically to S3, Google Drive, Dropbox, or Backblaze B2. If you have cron access, you can also trigger a remote backup endpoint via curl or wget, though most shared hosts limit how often cron jobs can run.
What does incremental backup mean?
An incremental backup saves only the files that changed since the last backup (whether full or incremental). Day 2 contains changes from day 1; day 3 contains changes from day 2. This keeps storage tiny and CPU light. Restore takes longer because you need the initial full backup plus every incremental in order.
How long are backups retained?
Most managed shared hosts retain 7 to 30 days of rolling backups. A 14 to 30 day retention window is the sweet spot for most sites – long enough to recover from a hack discovered weeks later, short enough to stay GDPR-compliant and storage-cheap. Going beyond 30 days only makes sense for PCI-DSS, HIPAA, or other regulated workloads.
Can I restore my website to a specific previous date?
Yes, if your backup solution supports point-in-time restore. JetBackup and CodeGuard both let you pick a date and restore in one click. UpdraftPlus premium and BlogVault offer similar functionality. If you only have manual phpMyAdmin + FTP backups, you restore the .sql.gz file and file archive from the date you need – slower but workable.
Are backups secure?
Reputable backup plugins and services encrypt backups in transit (HTTPS) and at rest. CodeGuard, UpdraftPlus premium, and BlogVault all support encryption keys. Your responsibility is to keep your cloud storage credentials safe – rotate access keys annually and never commit them to a public Git repo.
Will my website have downtime during backups or restoration?
Most modern backup plugins run in the background without affecting your live site. Restoration is where downtime happens – restoring files via FTP overwrites your live site, and database import locks the tables during the write. Plan a maintenance window of 30 minutes to a few hours depending on archive size. BlogVault and CodeGuard can restore to a staging environment to avoid live downtime.
Is there an additional cost for hosting with backup?
Basic daily backups are usually bundled with shared hosting at no extra charge. Premium features – off-site storage, incremental backups, longer retention, point-in-time restore – usually cost extra either as a host add-on (CodeGuard) or a plugin license (UpdraftPlus premium, BlogVault, BackupBuddy, Jetpack Backup). Free options exist but cap your retention and destination count.
Can I back up my website manually?
Yes. Open phpMyAdmin, select your database, click Export, and download a .sql or .sql.gz file. Then connect via FTP or SFTP and download your entire site folder (typically public_html). Compress both with clear date-stamped filenames and store them somewhere off the shared server. Manual backup is slower but works on every shared hosting account.
Final Verdict: Building a Resilient Shared Hosting Backup Plan
The best backup solution for shared hosting is not a single tool – it is a layered system that survives the constraints of the environment. Shared hosting gives you no SSH, restricted PHP, throttled cron, and tight memory limits. Most popular backup tools quietly fail under those conditions, which is why so many site owners discover their backup was broken only after a disaster.
Here is the plan I recommend, in order of priority:
- Daily automated plugin backup to off-site storage. UpdraftPlus free to Backblaze B2, or BlogVault if you can afford it. This is your primary defense.
- Host-native snapshot enabled. cPanel Backup or JetBackup, kept on the host as a free fallback layer.
- Monthly phpMyAdmin + FTP manual export to your laptop or external drive. This is the layer that works when everything else breaks.
- Quarterly restore drill on a staging subdomain. If you have not tested the restore, you do not have a backup.
Follow the 3-2-1 rule: three copies, two media types, one off-site. Keep 14 to 30 days of rolling retention unless compliance says otherwise. Document your retention window so GDPR reviews pass cleanly.
If you prefer an open-source MySQL-focused tool for the manual layer, phpMyBackupPro (the namesake of this site) is a free PHP script you can drop into your hosting account to schedule MySQL-only dumps to email, FTP, or a local folder. It is a useful complement to a full site backup plugin because it captures the database on its own clock, independent of WordPress.
Set up your first automated backup today. A backup you have not configured does not exist, and the failure you are protecting against is closer than you think.