KiraBackup

KiraBackup lets you export your entire WordPress site as a single ZIP package and import it on any WordPress installation. Use it for routine backups, disaster recovery, or site migration.

Key Features

• Selective export — choose exactly what to include: database, plugins, themes, uploads, must-use plugins.
• Small steps — exports and imports advance in steps of about 15 seconds driven by the browser, with a live progress bar. The database is read in slices of about 8 MB, so tables with very large rows do not exhaust PHP memory. Very large sites still take time, and a ZIP with a great many files gets slower to extend as it grows.
• The site is switched over at the very end — the database is imported into separate tables, URLs are replaced there, and the restored folders are prepared next to the live ones. Until then nothing on the site changes.
• A way back from any point — every step of the switch-over is written into a journal on disk before it is done, and the original folders and database tables are moved aside, not deleted. If the switch-over stops for any reason (time limit, out of memory, the server killing PHP, a power cut), the original site is put back on the next page load; if the database had already been swapped, the switch is finished instead. Before the restore starts, KiraBackup checks the free disk space.
• Check, then keep or roll back — after a restore the site as it was before (database and files) is kept for 7 days or until you click Everything is fine; Roll back puts it back in one click. If the restored site does not load at all, use the recovery address shown before the restore, put an empty file named kirabackup-recover.txt into wp-content by FTP, or run wp wpcbr recover --rollback (it also works with --skip-plugins --skip-themes).
• Any upload size — the browser sends the ZIP in slices. A slice the server refuses is resent smaller, a dropped connection is retried, and selecting the same file again continues where it stopped. You can also put the ZIP in the imports folder by FTP (it is used where it is and never deleted by KiraBackup) and choose it on the screen, or run wp wpcbr import <file.zip>.
• Two-step import — inspect the package contents before making any changes to your site.
• URL replacement — replaces the source site’s URLs with the destination’s throughout the database, including inside serialized PHP values and block editor markup.
• Clear when something goes wrong — if PHP stops a step (memory or time limit), the screen says which limit and what happened to the site: before the switch-over nothing changed, during it the original site was put back. The uploaded ZIP is kept, so the restore can be started again without uploading; leftovers are removed on the next run. Files that cannot be read are left out of a backup and listed in skipped-files.txt instead of failing it.
• Preflight warnings — alerts you to low memory, short execution time, or insufficient disk space before you start.

Typical Use Cases

• Migrate a site from a local development environment to a live server.
• Move a site to a new hosting provider or domain.
• Create a point-in-time backup before a major update.
• Clone a site for staging or testing.

Requirements

• PHP 7.4 or later with the ZipArchive extension enabled.
• WordPress 6.2 or later. Single-site installations only (not Multisite).
• Free disk space: during a restore the ZIP, its extracted contents and the database imported next to the current one (checked before the restore starts). The original folders are moved aside, not copied, so keeping them needs no extra space; the original database is kept as extra tables until you confirm the restore.

Limitations

• WordPress itself (wp-admin, wp-includes and the files in the WordPress folder: .htaccess, robots.txt, ads.txt, verification files of search engines and the like) and wp-config.php are not backed up or restored. Install WordPress on the new server as usual; wp-config.php and .htaccess hold that server’s own settings, and a copy from another server can stop WordPress from starting — and then no way back would work. Copy any of those files you need by hand. Backups made with older versions may contain them; they are skipped, and the screen says so.
• Translations (wp-content/languages) are not included; WordPress downloads them again on the new site (Dashboard → Updates).
• Only this site’s database tables (those with its table prefix) are backed up and restored. Another WordPress in the same database — including one whose prefix begins like this one, such as wp_b2_ next to wp_ — is left alone. Tables without the site’s prefix (made by a few plugins) are not included. Older backups that hold other tables are restored without them, and the screen names them.
• A folder on a different disk than wp-content cannot be switched over safely, so it is not restored; restore the other parts, or copy that folder by hand.
• Links and Windows junctions are not followed, and paths the server cannot read (for example over the Windows path-length limit) are skipped; both are listed in skipped-files.txt inside the backup.
• On sites that set DISALLOW_FILE_MODS, code (plugins, themes, must-use plugins) is not restored and the upload-limit helper is disabled; the database and uploads can still be restored.
• The SQL parser handles standard WordPress data well but may have difficulty with highly customised database schemas.
• URL replacement changes tables row by row, so a table without a primary key (made by a few plugins) keeps its old addresses, as with WP-CLI’s search-replace. A table whose key holds the address (a plugin’s list of URLs) is replaced too, key included. When a new address would make a value longer than its column holds, or the database refuses it (a CHECK constraint — for example a JSON column on MariaDB in a table whose key holds the address), the restore stops and changes nothing; restore without URL replacement and replace the addresses afterwards (for example with wp search-replace).
• The database is read table by table while the site keeps running. Each slice of a table continues after the last key read, so a row that is there for the whole backup is saved exactly once. When a table is done, the rows already saved are looked for again: a row that was deleted meanwhile — also one added again under a new key, as WordPress does when an expired transient is set again — is noted as removed, and a row whose other unique values changed is saved again as it is now, so such a name is not restored twice. A row that is added while its part of the table is being read may be in the backup or not. When an older backup holds a row twice under the same key or unique name, the restore keeps the later copy (the newer one); a backup of an older version can still hold an old and a new row that share no unique value (such as a post’s field set again), and both are restored. A table with neither a primary key nor a unique key on columns that are never empty (NULL) is read in an order made from the content of each whole row: for a very large table of that kind every slice reads the whole table, and the backup takes longer. Rows that hold exactly the same values are saved as many times as the table holds them, but cannot be told apart, and a row of such a table that is changed while the backup runs counts as removed and added again (it may be saved in its old form, its new form, both or neither).
• Generated columns (computed by the database) are saved without their values and computed again when restored.
• Rows that swap the values of a unique key built on part of a column (a prefix) or on an expression, while the backup checks that table, are not followed: one of them may be restored in its older form, or be missing. Unique keys on whole columns are followed.
• Backups made by 1.2.0 can be restored only by KiraBackup 1.2.0 or later. Complete Backup Restore 1.1 refuses them at the upload (“The backup manifest is invalid”), without changing anything: their database part may remove rows that changed while the backup ran, which 1.1 would apply to the live site. Backups made by 1.1 can still be restored by 1.2.0. If you switch between the two while a backup or restore is under way, neither goes on with the other’s: 1.1 says that no job is running (switch back to KiraBackup to finish it), and KiraBackup stops a backup or restore that 1.1 began, without changing the site, and removes the unfinished archive of such a backup. Each keeps its own restore point (the copy of the site from before its last restore) under its own names: a restore, “Roll back” or “Discard” in 1.1 leaves KiraBackup’s untouched, and “Everything is fine” in KiraBackup never removes 1.1’s. A backup made with 1.1 while a KiraBackup restore waits for your check also holds KiraBackup’s copy of the site, so it is larger. If you then restore that backup in 1.1, 1.1 changes every “%” in the values it puts back, so KiraBackup’s “Roll back” refuses without changing anything until “Roll back” in 1.1 has undone that restore.