Shared Hosting Backups Without False Assumptions

A WordPress update breaks a plugin, a developer deletes the wrong directory, or a payment succeeds but the order never reaches your store database. These are ordinary failures, not disaster-movie material. Shared hosting backups are what turn them into an annoying hour instead of a dead website, lost sales, or a rebuild from memory.

The uncomfortable part: a host having backups is not the same as you having a backup strategy. Provider snapshots can be limited, short-lived, unavailable during account trouble, or unable to restore the exact file or database state you need. Treat host-level backups as a useful safety net. Keep your own copies anyway.

What shared hosting backups should contain

A usable restore point is more than a ZIP file of public_html. Most dynamic sites need both their files and their database from roughly the same point in time. Files hold themes, plugins, uploads, application code, configuration files, and sometimes local caches. The database holds posts, user accounts, orders, settings, comments, and the data that makes the site function.

Email is a separate decision. If you use mailboxes on the hosting account, decide whether old messages matter enough to back up. For a small personal domain, perhaps not. For a business that receives invoices, customer requests, or account recovery messages by email, leaving mailbox history out of the plan is a bad bet.

Also account for files outside the obvious web root. Application configuration may sit one directory above public_html. Cron jobs, custom redirects, DNS records, SSL-related settings, and control panel settings may not be included in the backup format you expect. You do not need to archive every temporary file. You do need to know what a clean rebuild would require.

For most shared accounts, the backup set has four parts:

• Website files, including uploads and configuration files
• Database exports for every application database
• Email data, if mail is hosted in the account and has business value
• A short recovery note listing domains, software versions, cron jobs, and restore steps

That recovery note sounds unglamorous until six months pass and you cannot remember which PHP version your old application needed. Put it in the same offsite location as the backups, but do not store passwords or secret keys in plain text.

Do not confuse a host backup with your backup

Shared hosting is built around shared infrastructure and reasonable limits. A provider may run backups for operational recovery, but those copies are primarily part of its own platform management. They can help after a hardware problem or a mistaken deletion. They should not be treated as a guaranteed archive service unless the host explicitly documents retention, frequency, scope, restore options, and exclusions.

Read the policy instead of filling in the blanks yourself. Ask practical questions: How many restore points exist? Are databases included? Are email accounts included? Can you restore one file, one database, or only the whole account? Does restoring overwrite newer data? Is there a fee? Can you download the backup?

The answer may be “we do not provide customer backups.” That is not automatically a deal breaker. It is simply a clear line of responsibility. Cheap hosting stays cheap partly because it is not staffed like a managed recovery service.

At Ular.Host, the sensible assumption is the same one that applies to any budget-focused, self-service host: run your own backups, keep them outside the account, and verify that they restore. Hosting capacity is not a substitute for an independent copy of your data.

A practical backup schedule

Frequency depends on how much data you can afford to lose. A brochure site updated a few times a month can often live with a weekly full backup plus a copy before each change. A blog with daily publishing needs daily database backups at minimum. A store, membership site, forum, or booking system may need database backups several times per day because orders and user activity change constantly.

Start by defining your recovery point objective in plain language: “If the site fails, how much recent work can we lose?” If the honest answer is one day, daily backups are the floor. If the answer is one hour, a once-a-night backup job is not enough.

Storage and retention matter too. Keeping one current backup only protects you from a single failure. It does not protect you when corruption or malware has been sitting unnoticed for weeks. Retain several versions. A simple approach is daily copies for the last week, weekly copies for the last month, and monthly copies for a few months. For a small site, this is usually manageable without building an enterprise archive.

Watch your 6GB disk allocation if your account has one. Backups stored inside the hosting account consume the same limited space as the website. They can fill the account, cause application failures, and disappear with the account if the account itself is damaged. Generate the archive locally if possible, then move it off the server promptly.

Keep copies off the hosting account

The basic rule is simple: a backup stored only on the server it protects is not a backup. It is a duplicate waiting for the same problem.

Download manual exports to an encrypted local drive, send scheduled archives to independent object storage, or use a backup service that connects through SFTP or another supported method. The destination matters less than independence. It should be on a different system, under credentials you control, with enough retention to be useful.

For WordPress and similar applications, a plugin can automate exports and offsite delivery. That is convenient, but convenience is not verification. Plugins can fail after an update, run out of disk space while creating archives, or silently exclude large upload directories. Check the job logs and inspect a recent backup occasionally.

For custom PHP, Laravel, Drupal, MediaWiki, or static sites with a database, a scheduled script may be cleaner. Export the database with the appropriate command-line tool, archive the required files, encrypt the archive if it contains customer data, and upload it offsite. Keep the script small and readable. A complicated backup system is just another thing that can break.

Test restores before you need one

A backup is proven only when it restores. This is where many site owners find out that their archive contains files but no database, has a corrupted SQL export, or restores an old configuration that points to the wrong environment.

Testing does not need to be dramatic. Once every few months, restore a copy to a local development environment, a temporary subdomain, or a separate test account. Confirm that the home page loads, users can log in, media files appear, forms work, and the database contains the expected recent records. Delete the test environment after checking it, especially if it contains real customer information.

Write down the time required. Restoring a 500MB blog from an archive is different from recovering a larger store with a busy database. Knowing the actual recovery time helps you decide whether your schedule and storage approach match the risk.

Backups are not security controls

Good backups reduce the damage from mistakes, ransomware, failed updates, and provider-side incidents. They do not stop weak passwords, vulnerable plugins, exposed admin accounts, or compromised developer devices.

Keep application software updated, remove abandoned plugins and themes, use unique passwords with two-factor authentication where available, and limit who can access the hosting panel. Protect backup destinations too. An attacker who can delete both the production site and its offsite archives has turned your backup plan into theater.

Use versioned or retention-protected storage when it fits your budget. This creates friction against accidental or malicious deletion. It is not magic, and it may cost more, but it is worth considering for sites that generate revenue or hold irreplaceable data.

The cheapest backup plan is usually a small scheduled export, stored somewhere independent, with a calendar reminder to test it. Set that up before the next plugin update, database cleanup, or late-night file edit. Your future self does not need a heroic recovery system. It needs one copy that works.