Freelancer's Guide to Backups Without Plugins

Quick answer: You can back up a client's WordPress site without installing any plugin by connecting to the server over SSH from the outside, archiving the site directory, dumping the MySQL database with mysqldump, and streaming both to storage that lives outside the hosting account. This works on any host that gives you SSH access, adds nothing to the site itself, and — critically for freelancers — keeps the backup under your control rather than the client's hosting account. You can script it yourself with cron and rsync, or use a managed agentless service so you aren't the single point of failure at 2am.

If you build WordPress sites for a living, backups are the least glamorous part of the job and the one that decides whether a bad Tuesday costs you two hours or a client. The uncomfortable part is that most freelancers inherit their backup strategy by accident: a plugin the last developer installed, a host feature nobody has tested, and a vague assumption that "it's probably covered."

This guide covers why the plugin-per-client approach breaks down specifically at freelancer scale, how to back up a WordPress site over SSH with no plugin at all, exactly what to include and exclude, how to script it yourself, when a managed agentless service makes more sense than your own cron jobs, and how to position backups as a paid deliverable instead of unpaid anxiety.

Why Don't Backup Plugins Work Well for Freelancers?

Backup plugins aren't bad software. They're software solving a single-site problem, being used to solve a portfolio problem. Those are different jobs, and the gap shows up in specific, predictable ways:

• The backup runs inside the thing being backed up. A plugin executes as PHP on the client's server, competing with real visitors for workers and memory. On cheap shared hosting — where a lot of client sites live — a nightly archive job is exactly the kind of thing that trips resource limits.
• It depends on WP-Cron, which depends on traffic. WordPress's scheduler only fires when someone visits the site. A low-traffic brochure site can go days without triggering a scheduled backup, and nothing tells you. This is the single most common cause of silent backup failure.
• Failures are silent by default. The dangerous state isn't "the backup failed." It's "the backup failed eight weeks ago, the dashboard still shows a green tick, and nobody looked." We've written about how backup plugins fail quietly — the pattern repeats across every plugin.
• The backup is stored where the risk is. Plugin archives usually land in wp-content/. If the account gets compromised, suspended, or wiped, the backups go with it. That's the whole reason restoring a hacked site so often fails at the last step.
• It multiplies by client count. Thirty sites means thirty plugin installs, thirty update cycles, thirty sets of settings, thirty licence renewals, and thirty dashboards nobody checks. The per-site cost is small; the portfolio cost is a part-time job.
• You often don't control the client's plugin list. Clients deactivate things. New developers "clean up" plugins. An in-site backup tool is only as durable as the client's restraint.
• It's another attack surface. A plugin with filesystem and database access, sitting in a public-facing install, is a category of vulnerability that a lot of real-world WordPress compromises have run through.

None of this means plugins are useless. It means the backup layer you stake your reputation on should not live inside the site it's protecting.

Can You Back Up a WordPress Site Without a Plugin?

Yes — and it's the approach most sysadmins would have chosen from the start. A complete WordPress backup is only two things:

1. The files — the entire application directory: WordPress core, wp-content (themes, plugins, uploads), and wp-config.php.
2. The database — a full MySQL/MariaDB dump containing posts, pages, users, settings, WooCommerce orders, and everything else that isn't a file.

Neither requires WordPress to be running. Neither requires PHP. If you have SSH access to the server, you have everything you need. That's what "agentless" means: the backup is pulled from outside instead of pushed from inside.

What you need before you start

• SSH access to the hosting account (key-based is strongly preferred over passwords).
• The absolute path to the site's document root — often something like /home/username/public_html.
• Database credentials, which you don't need to ask the client for: they're already in wp-config.php.
• Somewhere to put the archives that isn't the same hosting account.

How to Back Up a Client WordPress Site Over SSH

Here is the manual process, end to end. Run it once by hand on a new client site before you automate anything — it surfaces path and permission surprises while you're watching, rather than at 4am.

Step 1: Read the database credentials from wp-config.php

ssh client@server.example.com
cd /home/client/public_html
grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" wp-config.php

Reading credentials live from wp-config.php matters more than it looks: when the client changes hosts, rotates a database password, or a host migration rewrites the config, a backup that parses the file at run time keeps working. One that stored the credentials at setup time silently starts failing.

Step 2: Dump the database

mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  -u DB_USER -p'DB_PASSWORD' DB_NAME > /tmp/db-$(date +%F).sql

• --single-transaction gives you a consistent snapshot on InnoDB tables without locking the site.
• --quick streams rows instead of buffering the whole table in memory — important on shared hosting.
• --default-character-set=utf8mb4 prevents the emoji-and-accents corruption that shows up weeks later in restored content.

If mysqldump isn't available, WP-CLI's wp db export does the same job.

Step 3: Archive the files

tar -czf /tmp/files-$(date +%F).tar.gz \
  --exclude='wp-content/cache' \
  --exclude='wp-content/uploads/cache' \
  --exclude='wp-content/backups*' \
  -C /home/client public_html

Step 4: Pull the archives to storage you control

rsync -avz client@server.example.com:/tmp/files-*.tar.gz /backups/clientname/
rsync -avz client@server.example.com:/tmp/db-*.sql     /backups/clientname/
ssh client@server.example.com 'rm -f /tmp/files-*.tar.gz /tmp/db-*.sql'

That last line matters. Leaving archives on the client's server eats their disk quota and, worse, leaves a downloadable copy of their entire database sitting in a predictable location.

Step 5: Verify the backup is actually a backup

An unverified backup is a guess. Minimum checks:

gzip -t files-2026-09-16.tar.gz          # archive integrity
tail -c 100 db-2026-09-16.sql            # must end with "Dump completed on ..."
ls -lh files-*.tar.gz db-*.sql           # sizes sane vs. yesterday?

That -- Dump completed marker at the end of a MySQL dump is the single best cheap signal you have. A dump that got truncated by a timeout or a disconnect is missing it — and a truncated dump restores a partial database without ever announcing that anything went wrong.

What Should You Include and Exclude in a WordPress Backup?

Always include:

• The full WordPress install — core, themes, plugins, wp-content/uploads
• wp-config.php (a restore is painful without it)
• .htaccess and any custom server config in the document root
• A complete database dump, all tables, not just wp_posts

Safe to exclude:

• wp-content/cache/ and page-cache plugin directories — regenerable, and often gigabytes
• Existing backup plugin archives (wp-content/backups, wp-content/updraft) — backing up your backups doubles storage for nothing
• node_modules/, build artefacts, and local dev folders
• Log files that grow without bound

Never exclude because "it's probably fine": uploads, custom themes, or mu-plugins. The one folder you skip is the one that turns out to contain a decade of client PDFs. For unfamiliar custom applications, the safe default is archiving everything — silently skipping an unknown folder is the one mistake a backup tool must never make.

Should You Script It Yourself or Use a Managed Service?

Scripting your own SSH backups is a legitimate, respectable choice. It's also a system you now own.

Rolling your own makes sense when:

• You manage a handful of sites on servers you control
• You're comfortable with cron, key management, and log monitoring
• You want zero recurring cost and total control over storage
• You'll genuinely build and test alerting, not just intend to

A managed agentless service makes sense when:

• You're managing client sites across many different hosts, each with its own quirks
• Nobody is paying you to maintain backup infrastructure
• You need failures to reach you on the day they happen, not the day you need the backup
• You need restores to be fast and boring under pressure — including by someone who isn't you
• Backups are a billable deliverable and need to look like a service, not a folder on your laptop

The honest tiebreaker is the part nobody enjoys: monitoring and restore testing. Writing the backup script takes an afternoon. Noticing that site #17's key rotated and its backup has failed for six weeks requires infrastructure you have to build and then actually watch. Most freelancers build the first part and never finish the second.

Where BackupYourSite fits

BackupYourSite is the second option built as a product, using exactly the SSH approach described above. You add the host, username and folder — or generate an ed25519 keypair in the dashboard and paste the public half into the hosting panel — and the nightly run connects in from outside, reads the WordPress database credentials from wp-config.php at run time, tars the files, dumps the database, and streams both back over the same SSH channel. Nothing is written to the client's disk, and nothing is installed on the site.

The specifics that matter for freelance work:

• No plugin, so nothing for a client to deactivate and nothing competing with their visitors for PHP workers.
• Every archive is verified before it counts as a success — integrity checks plus that dump completed marker — so a broken backup gets retried and reported rather than stored.
• Failures alert immediately, with a daily summary covering every site including any enabled one that silently didn't run. That's the monitoring layer most DIY setups never finish.
• One-click restores of files, database, or both — listed straight from storage, so the list shows what can genuinely be restored rather than what a log claims.
• Retention that can't hurt you — old backups are pruned only after a fully clean run, so a bad night never deletes your last good copy.
• Any PHP application, not just WordPress — Laravel, legacy custom apps, the client site you inherited and don't want to think about.
• Whitelabel on the Agency plan — your brand, logo and colours, so backup reporting looks like part of your service rather than a third party's.

Plans start at $15/month for 3 sites (Starter), $30/month for 10 (Business), and $75/month for 30 sites with full whitelabel (Agency) — with up to 60% off annually and 25 GB to 500 GB of managed offsite storage included. There's a free 30-day trial so you can run a real client site through a full backup and a real restore before paying anything. See pricing and the full feature list.

How Do You Charge Clients for Backups?

Most freelancers do backups for free, badly, and worry about them constantly. The better model is to make it a line item:

• Bundle it into a care plan. "Monthly maintenance: updates, uptime monitoring, offsite backups, restore on request." Backups are the easiest part of a retainer to justify, because the client understands the downside instantly.
• Price on outcome, not cost. Your input cost per site is a few dollars a month. The value is a site that can be brought back in an hour instead of rebuilt from scratch. Charge accordingly.
• Sell the restore, not the backup. Nobody wants a backup. Everyone wants "we can put it back." Say that.
• Make the reporting visible. A monthly note saying backups ran, verified, and were tested is the cheapest trust-building artefact in the business — and whitelabelled reporting means it carries your name.
• Keep the backup in your account, not theirs. This is professional self-protection as much as client service. If a client stops paying their host, or a relationship ends badly, a backup tied to their hosting account disappears with it.

A 20-Minute Backup Audit for Your Client Portfolio

Do this once, this week, for every site you're responsible for:

1. List every site and where its backup actually lives. Not where you think — open it and look.
2. Check the date of the most recent successful backup. Anything older than the stated schedule is a failed system, not a late one.
3. Check the oldest available backup. If retention is 7 days, you cannot recover from a problem that went unnoticed for two weeks — and slow-burn problems usually do.
4. Confirm at least one copy is outside the hosting account. If every copy lives in the account, you have a single point of failure, not a backup.
5. Do one real restore, to a staging site. This is the only step that converts belief into knowledge. Most backup strategies fail here for the first time, on the worst possible day, unless you test them on an ordinary one.

Frequently Asked Questions

Can I back up a WordPress site without installing a plugin?

Yes. A WordPress backup is just the site's files plus a MySQL database dump, and both can be taken over SSH from outside the server — tar for the files, mysqldump for the database. No plugin, no PHP execution on the site, and it works even when WordPress itself is broken or won't load.

Do I need SSH access to back up a client's WordPress site?

For a plugin-free backup, yes — SSH (or SFTP plus a way to dump the database) is what lets you archive files and export the database from outside. Most shared, VPS and managed WordPress hosts provide SSH access; a few very cheap shared plans restrict it, and on those you'd need to enable it, upgrade, or fall back to a plugin-based approach.

Where do I get the database credentials for a client site?

They're already in wp-config.php in the site's root, as DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. Reading them at run time rather than storing a copy is better practice, because the backup keeps working after a host migration or a password rotation instead of failing silently.

Is an SSH backup safer than a backup plugin?

It's safer in two specific ways. It adds no plugin with filesystem and database access to a public-facing site, and the archives don't sit inside wp-content where a compromise or an account suspension would take them along with everything else. It also doesn't depend on WP-Cron, which means low-traffic sites don't quietly stop backing up.

How often should I back up client WordPress sites?

Daily is the sensible default for most business and brochure sites. WooCommerce stores, membership sites and anything with frequent user-generated content justify more frequent database backups, since a day of lost orders is a real cost. The more important variable is usually retention: keeping 30 days beats keeping 3, because problems are often discovered weeks after they start.

What's the difference between agentless backup and a backup plugin?

A plugin runs inside your site, using its PHP, its memory and its scheduler, and typically stores archives on the same server. An agentless backup connects in from outside over SSH and pulls the data to independent storage. The practical consequences: no performance impact, no plugin to maintain or be deactivated, no dependency on WordPress running, and a backup that survives things that take the hosting account down.

Can I restore just the database without restoring the files?

Yes, and you should be able to — it's the fastest fix for a bad plugin update or a botched content import, because re-sending the whole file tree is far slower. Any backup system worth using lets you restore files, database, or both independently.

How do I know my backups are actually working?

Two checks, and both are non-negotiable. First, verification: the archive passes an integrity check and the database dump ends with MySQL's own -- Dump completed line. Second, a real restore to a staging environment, done on an ordinary day. A backup you've never restored is an assumption. Automated failure alerts close the gap between the two.

Should backups be in my account or the client's?

Yours, or a service account you control, for practical reasons rather than territorial ones: a backup tied to the client's hosting account disappears when that account is suspended, cancelled, or handed to another developer — which is exactly the moment it's most needed. Handing over a copy at the end of an engagement is straightforward; recovering one from an account you've lost access to is not.

The Bottom Line

The plugin-per-client model fails freelancers for a structural reason, not a quality one: it puts the backup inside the thing that breaks, on the server that gets suspended, behind a scheduler that depends on traffic, reporting to a dashboard nobody opens. At one site that's a small risk. Across twenty client sites it's a certainty waiting for a date.

Backing up over SSH fixes the structure. The site runs nothing, the archives live somewhere the hosting account can't take down, and the backup keeps working when WordPress doesn't. You can build that yourself with cron, mysqldump and rsync — the commands above are the whole of it — as long as you also build the verification, alerting and restore tooling that make it trustworthy at portfolio scale. If you'd rather not own that infrastructure, BackupYourSite is the same agentless SSH approach delivered as a service: verified daily backups, offsite storage, immediate failure alerts, one-click restores, and whitelabel reporting you can put your own name on. Either way, the thing worth doing this week is the audit — because the only backup that counts is the one you've actually restored.