Backups are the foundation of every WordPress site’s security. Even if you use hosting that automatically creates backups, it’s worth having your own, independent protection — ideally one that doesn’t depend on a single plugin or a single server.

Why Are Backups Important?

  • Hacker attacks - ability to quickly restore the site
  • Update errors - plugins or themes can “break” the site
  • Accidental deletion - easy to accidentally delete important content
  • Server failure - though rare, they can happen

The Golden Rule: Backups Must Leave the Server

A backup only matters if it survives the very thing it’s meant to protect against. A backup sitting on the same server as the site goes down with it — in a hack, disk failure, or ransomware encryption you lose both the site and its copy in one move. That’s why every backup should physically leave the server: go to external cloud storage (Google Drive, Amazon S3, Backblaze) or an independent file server.

Should You Rely on a Backup Plugin?

For years the default answer was UpdraftPlus. Today it’s a choice that fails more often than it helps — especially on a site you actually want to be able to restore after a disaster:

  • It stores copies in wp-content by default — that is, on the same server, often in a publicly accessible directory. An archive with your entire database at a guessable address is a ready-made leak.
  • It backs up from inside an environment that may already be compromised — if the site has a backdoor, the plugin will happily pack it into the copy.
  • It chokes on larger sites — generating an archive in PHP runs into memory and execution-time limits, producing truncated copies that look fine until your first restore attempt.
  • It’s another plugin with access to your whole database and files — meaning extra attack surface.

If for some reason you must use a plugin, configure it to send copies exclusively to external cloud storage and never leave them on the server. The methods below are more reliable, though.

Methods You Can Rely On

Database and File Dumps at the Server Level

The most reliable backup is created outside WordPress — directly on the server, as a cron job. The database via mysqldump, the files via tar, the whole thing pushed off the hosting right away.

For a VPS or dedicated server, a convenient ready-made tool is automysqlbackup:

# Installation
apt-get install automysqlbackup

# Configuration
nano /etc/default/automysqlbackup

The tool automatically creates:

  • daily copies (last 7 days),
  • weekly copies (last 5 weeks),
  • monthly copies (unlimited).

By default they land in /var/lib/automysqlbackup/ — remember to sync them further, off the server.

Versioning Your Code in Git

It’s worth keeping all of your site’s code — core, theme, plugins, and configuration files — in a Git repository (e.g. a private one on GitHub). A remote is by nature an off-server copy, and after an attack git diff shows every injected and altered file in seconds. Git versions code, not data, though — you still protect the database and the wp-content/uploads directory with the dumps from the previous point.

Hosting’s Automatic Backups (Installatron)

If your panel has Installatron (e.g. in DirectAdmin), you can enable its built-in backups:

  1. Log in to the panel,
  2. go to Installatron,
  3. select your WordPress installation,
  4. click “Backup” and set a schedule.

This is convenient, but treat it as a supplement — hosting backups usually sit on the same provider’s infrastructure, so make sure to pull them off the server too.

Backup Best Practices

  1. 3-2-1 Rule: 3 copies, 2 different media, 1 off-site copy
  2. Test restore: Regularly check whether backups actually restore
  3. Automation: Don’t rely on manual backup creation
  4. Encryption: Encrypt copies containing personal data

Summary

Regularly create backups and store them off the site’s server — preferably automatically, at least once a week. Don’t build your whole strategy on a single plugin: server-level dumps and versioning your code in Git are more dependable. Remember, the question isn’t “if” you’ll lose data, but “when”.