seljeBackup

One-click restore or site migration. Backups are standard .sql.gz and .zip files and are restored by hand (see "How do I restore or rebuild my site from a backup?" below). Incremental backups Official multisite support

Every backup is two ordinary files, so no plugin is needed: …_database.sql.gz (posts, pages, settings, users, orders) and …_files.zip (wp-content with themes, plugins and uploads, plus wp-config.php without its security keys, and .htaccess). The same guide is in the plugin under Backups -> How do I restore or rebuild my site? You need: both backup files (download them in the plugin or from your cloud storage), a file manager or FTP/SFTP, and phpMyAdmin or your host's database tool. For a full rebuild you also need WordPress itself from wordpress.org: the core folders wp-admin and wp-includes are not in the backup by default, because they are identical for every site and can always be downloaded again. A. Quick restore (WordPress still runs on the same site) Make a new backup first, so you can go back. Database: in phpMyAdmin select the site's database, choose Import, pick the .sql.gz file (no need to unzip) and run it. The WordPress tables are replaced. Files (only if they are broken or missing): unzip …_files.zip and upload the wp-content folder, replacing the existing files. Log in (users and passwords are as they were in the backup), click Save under Settings -> Permalinks and clear any cache. B. Full rebuild (empty hosting, new server or new address) Unzip …_files.zip and open seljebackup-manifest.json: note the WordPress version, table prefix and old site address. Download WordPress (preferably the same version: https://wordpress.org/download/releases/) and upload the contents of its wordpress folder to your web folder (often public_html). Do not run the installer. Upload from the backup: wp-content (replace the one from WordPress), wp-config.php and .htaccess. Create an empty database and user in your hosting panel. If they differ from the old site, change DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php. Do not change $table_prefix. Backups never contain the real security keys: replace the eight lines that say "put your unique phrase here" with new ones from https://api.wordpress.org/secret-key/1.1/salt/ (if you skip this, WordPress creates keys by itself). Import …_database.sql.gz with phpMyAdmin. Too big for phpMyAdmin? Use your host's import tool or SSH: gunzip < backup_database.sql.gz | mysql -u USER -p DATABASE New address? Run wp search-replace 'https://old-site.com' 'https://new-site.com' --all-tables (WP-CLI) or use a plugin such as Better Search Replace. Never use find/replace on the .sql file itself; it breaks serialized settings. Log in at /wp-admin (everyone has to log in again, because the security keys are new), click Save under Settings -> Permalinks, clear caches and check some pages and images. In seljeBackup -> Storage, connect each storage again (or enter its password again): saved connections are protected with the old security keys. If "Files" was set to "The entire WordPress folder", WordPress core is already in the zip: skip step 2. If something goes wrong "Error establishing a database connection": the database details in wp-config.php are wrong (step B4). Only the front page works: Settings -> Permalinks -> Save, or upload .htaccess again. Missing images: wp-content/uploads was not uploaded completely. Redirects to the old address: the search-and-replace (B6) was not done for all tables. Import stops or times out: use the host's import tool or the SSH command in B5.

Yes, it is the most important folder. WordPress core (wp-admin, wp-includes) can always be downloaded again, which is why it is left out by default, but wp-content holds everything that is unique to your site: uploads: your images and documents. Usually irreplaceable, and usually the largest part. themes and plugins: can be reinstalled from WordPress.org, but not premium or custom-made ones, edited files, or the exact versions you run. Restoring from a backup is much faster and brings back a working site in one step. mu-plugins, languages and other plugin folders: small, often forgotten, and needed for the site to work the same way. Parts of wp-content that are not needed are skipped automatically: cache folders, other plugins' backups, upgrade leftovers and logs. When a smaller backup makes sense: if your files rarely change but your database does (orders, comments, form entries), you can schedule Database only backups and click Back up now with "Database + files" after uploading media or updating plugins. Separate schedules for database and files are planned. Very large, rarely changing folders (for example an old video archive that is stored elsewhere too) can be skipped under "What takes up space?" on the Dashboard.

Open Dashboard -> What takes up space? and click Analyze now. It measures folders, the largest files and database tables, shows what goes into the backup, and gives tips. Common causes: several resized copies of every uploaded image, old backups from other plugins, cache folders, large log files, many post revisions and WooCommerce/Action Scheduler logs.

In wp-content/seljebackup-<random>/. The folder is blocked from web access (.htaccess, web.config, index files) and has an unguessable name, because some servers (nginx) ignore .htaccess. To store backups outside the web root, add define('SWPB_BACKUP_DIR', '/path/outside/public_html/backups'); to wp-config.php.

Yes, that is what it is built for. Backups run in short steps (a few seconds each) that continue in the background. If the host kills a step, the plugin notices, retries with smaller steps, and explains in plain language if it still cannot continue.

No. Backups still work while the admin page is open, and scheduled backups continue via WP-Cron every 5 minutes. For faster scheduled backups, add the Cron URL to a cron service.

So that your backups and access tokens go directly between your site and your own account, with no third-party server in between, and so that the plugin does not depend on a service run by the developer. It takes about 10 minutes, once, and the setup guide in the plugin walks you through it.

Only if the Google app is left in "Testing" mode (access then expires after 7 days; publish the app as described in the guide), if you remove the app's access in your Google account, or if you change the client secret. The plugin emails you when an upload fails.

Its settings, credentials and backup list are removed. Backup files are deliberately left on the server and in your cloud storage. Delete the wp-content/seljebackup-<random>/ folder yourself if you no longer need them.