Back up a WordPress site on your server

WordPress on a Linux server of your own: nginx or Apache, PHP, and MySQL or MariaDB on the same machine, with root access over SSH. This page says what NeverWiped backs up for such a site, what to check, and how to bring back a file, the media, the database or the whole site. WordPress in Docker containers: see a VPS running Docker.

What the agent finds

• The site’s files: /var/www, /srv, and the web roots declared in your nginx, Apache or Caddy configuration. That is WordPress itself, wp-config.php, and wp-content with its themes, plugins and uploads.
• The database: every MySQL or MariaDB database on the server, exported with mysqldump (or mariadb-dump) --all-databases --single-transaction. The tables are read from one snapshot, without locking the site, with the users and their rights (a database). As root, it uses /root/.my.cnf when there is one, otherwise /etc/mysql/debian.cnf when it exists.
• The configuration: /etc, so the web server, PHP and certificate settings, and the cron tables.

Excluded by default: /var/cache, **/node_modules and **/.cache (what is backed up).

Check the plan before you accept it

• The database is in the plan. If the install prints that /var/lib/mysql exists but no reachable server was found, the database is not backed up: check that MySQL or MariaDB is running and that its client tools are installed, then run the install again.
• A database on another machine (the DB_HOST of wp-config.php is not the server itself) is not exported. Only the databases on the server, or in its containers, are.
• Caches and old archives inside the site. A cache plugin’s folder can be left out with --exclude /var/www/site/wp-content/cache. Archives made by a backup plugin can be left out with --preset archives, but only if they are copies of what the plan already holds.
• Old tables not in InnoDB. The backup log says when MyISAM or Aria tables are found: they are not read from the same snapshot as the rest. Converting them is explained in a database.

Bringing things back

• One file, such as wp-config.php: restore it into a separate folder, then copy it back (one file).
• Deleted media, or a plugin update that broke the site: restore the folder from the night before, compare it with diff -rq, then copy back what you need (a folder).
• The database only (a bad import, a plugin that rewrote tables): take your database out of the dump, keep the damaged one aside, and import it alone. Its name is the DB_NAME of wp-config.php (a database).
• A hacked site: restore the files and the database from a date before the intrusion into a separate folder, compare, then put them back. Find how the attacker got in first, or it starts again. If they had root on the server, read the known limits.
• The whole server: on the new server, install the web server, PHP and MySQL or MariaDB, then follow a whole server.

Before a big update (WordPress, the theme, a shop plugin), run neverwiped backup now.

What it does not do here

• No root, no NeverWiped. On shared hosting without SSH and root, the agent can’t be installed (the agent). Your host’s backups, or a WordPress plugin, are then the way.
• Nothing in the WordPress admin. NeverWiped is not a plugin: everything happens on the server, with neverwiped commands, and in your NeverWiped dashboard.
• Orders, comments and posts since the last backup are in none of them. You go back to the time of a backup, not to any moment in between.
• One copy: your backups are stored once, on one storage server (known limits).

Start

On the server, as root:

curl -fsSL https://neverwiped.com/install.sh | sh

Then follow getting started. Other servers: all use cases.

Last reviewed: 6 November 2026.