# Recovering a site without WordPress There are two tools for this, both requiring nothing but PHP: 1. **The recovery installer** (`aisv-installer`) — a guided, one-click web wizard that rebuilds a whole site on a bare server. Best for "my site is gone, put it back". 2. **The extractor** (`tools/aisv-extract.txt`) — a command-line tool that just unpacks an archive into `database.sql` + `files/`. Best for pulling one thing out of a backup, or when you want to do the rebuild by hand. --- ## One-click recovery onto a bare server (the installer) Use this when there is **no working WordPress** at the destination — a dead site, a new host, a fresh server. 1. In a working AI-SiteArk dashboard, go to **Help & guide → Download recovery installer**, and save the file as `aisv-installer.php`. (It ships as a `.txt` so it can never run by accident inside the plugin folder — rename it to `.php`.) 2. Create an **empty** database on the destination server, and note its name, user, password and host. 3. Upload `aisv-installer.php` **and** your `.aisv` backup into the target web directory (e.g. `public_html`). For a split backup, upload every volume. 4. Open the installer in a browser — `https://your-new-site.com/aisv-installer.php`. 5. Enter the empty database's details and the new site address, then **Restore this site**. The installer imports the database, extracts your files, downloads the matching WordPress core, rewrites every URL for the new location (serialization-safe), and writes a fresh `wp-config.php`. 6. **Delete `aisv-installer.php` and the `.aisv` file(s) afterwards** — they hold your data and database credentials. WordPress core is fetched automatically from wordpress.org; if that server can't reach it, upload the WordPress files yourself and re-run. --- # Opening a backup without WordPress Your `.aisv` backup is not a black box. If WordPress is gone, the plugin is broken, or you simply want to look inside an archive, you can open it with one PHP file and nothing else. The tool lives at `tools/aisv-extract.txt` inside the plugin. Copy that single file anywhere — it needs no WordPress, no database, and no AI-SiteArk. **Requirements:** PHP 7.4 or newer. `openssl` is only needed for password-protected archives. --- ## Look inside an archive ```bash php aisv-extract.txt --list backup.aisv ``` ``` archive : backup.aisv volumes : 1 created : 2026-07-10T08:42:51+00:00 site : https://example.com prefix : wp_ encrypted: no database entries : 25 tables : 14 (wp_commentmeta, wp_comments, wp_options, wp_posts, …) files : 4128 (312,884,201 bytes) ``` ## Extract everything ```bash php aisv-extract.txt --extract=./recovered backup.aisv ``` You get: ``` recovered/database.sql every table, view, trigger and event recovered/files/ your wp-content files, laid out relative to wp-content/ ``` For a password-protected backup, add `--password=YOUR-PASSWORD`. A wrong password is rejected before anything is written. Only need one half? Use `--sql-only` or `--files-only`. --- ## Rebuild a site from the extracted parts 1. **Install WordPress normally** and create an empty database. 2. **Import the database:** ```bash mysql -u USER -p DBNAME < recovered/database.sql ``` 3. **Copy the files** in `recovered/files/` over your `wp-content/` directory. 4. **Point `wp-config.php`** at the database you just imported (`DB_NAME`, `DB_USER`, `DB_PASSWORD`) and make sure `$table_prefix` matches the `prefix` shown by `--list`. 5. **If the site has moved to a new domain**, the database still contains the old URL. Fix it with WP-CLI, which rewrites serialized data safely: ```bash wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables ``` 6. **Re-save permalinks** (Settings → Permalinks → Save) so the rewrite rules match the restored site. *(A normal AI-SiteArk restore does this for you automatically.)* WordPress core files are not in the archive — they are not worth backing up, because you can download an identical copy from wordpress.org at any time. Neither is `wp-config.php`, which holds credentials specific to the server it came from. --- ## Multi-volume backups If you set a part-size limit, a backup is written as `backup.aisv`, `backup.aisv.2`, `backup.aisv.3`, and so on. Keep every volume in the same directory and point the tool at the **first** one — it finds the rest automatically. ## Incremental backups An incremental archive contains only the files that changed since its base. The tool tells you when this is the case and names the base it needs: ``` NOTE: this is an INCREMENTAL backup (seq 3). It contains only files changed since its base: backup-base.aisv Extract that base first, then extract this one over the top. ``` Extract the base into a directory, then extract the incremental into the **same** directory so its changed files land on top. --- ## The archive format, briefly Should you ever need to write your own reader: a `.aisv` file is a 6-byte magic `AISV1\n`, followed by a flat sequence of entries. Each entry is ``` [uint32 big-endian header length][header JSON][uint64 big-endian payload length][payload] ``` The first entry is always the manifest, and it is always stored unencrypted so a tool can learn how to read the rest. Database entries are gzip-compressed. When the archive is password-protected, every entry after the manifest is encrypted with AES-256-CTR using a PBKDF2-SHA256 key (100,000 iterations) derived from your password and the salt recorded in the manifest; each entry carries its own IV. Because CTR is a stream cipher, payload length always equals plaintext length. Entries never straddle a volume boundary, so each volume is a self-contained sequence.