# BackupScope: full reference > BackupScope is a WordPress backup plugin for full site backups (files + database) that works on large sites. It scans first, backs up in small resumable steps, picks a standard ZIP up to 5 GB or a streaming ZIP64 archive above that, exports the database without mysqldump and verifies every backup before keeping it. The free plugin is complete, not a trial. BackupScope Pro adds scheduled backups, backup history and retention, S3-compatible off-site storage, one-click restore with a safety backup, email notifications with password-protected download links, Storage Analytics, Safe Cleanup with a 30-day Cleanup Trash, and Media review. Website: https://backupscope.pro · Support: support@backupscope.pro Current versions: BackupScope 1.0.1 (free), BackupScope Pro 1.0.0. ## Facts - Free plugin: full backup (files + database) or custom backup of chosen areas: database, WordPress core & config, plugins, themes, uploads, other wp-content folders, other root files. - Scan first: shows each area and folder with file count and size; the estimate updates when you untick items. - Automatically excluded: BackupScope's own storage, other backup plugins' archive folders (updraft, ai1wm-backups, backups-dup-lite, wpvividbackups and similar), caches (cache, et-cache, litespeed), wp-content/upgrade, .git/.svn/.hg/node_modules, .well-known and temporary files. - Backups run as a job in small resumable steps with a lock; an interrupted request continues from the last saved position. - Engine routing: up to 5 GB (estimated) a standard ZIP via ZipArchive; above 5 GB a streaming ZIP64 archive written in batches; automatic fallback to streaming if the standard engine fails. 5 GB is a routing threshold, not a size limit. Configurable with BACKUPSCOPE_BATCH_THRESHOLD (bytes) or the instabackup_batch_threshold_bytes filter. - Database export without mysqldump, through WordPress's own connection, paging through tables by key; very large values written in chunks so imports work with a default max_allowed_packet; binary and BIT columns exported exactly. - Verification: every archive entry is read back and its CRC-32 checked; manifest.json and database/database.sql must be present. A failed backup is discarded and the previous one kept. - Backup file: one standard ZIP containing manifest.json, database/database.sql and files/wordpress/ (plus files/external/ for folders outside WordPress). - Storage: wp-content/uploads/backupscope/, protected from web access (deny-all .htaccess / web.config, index files) with unguessable file names; downloads only for logged-in administrators. Custom folder via BACKUPSCOPE_STORAGE_DIR. - Free keeps the latest backup; the previous one is deleted only after the new one is created and verified. - Deleting the plugin deletes stored backups unless BACKUPSCOPE_KEEP_BACKUPS_ON_UNINSTALL is true. WordPress Multisite is not supported yet. - The free plugin makes no requests to external services and collects no data. - Pro scheduled backups: daily, weekly or monthly at a chosen time in the site time zone; full or custom; missed-run detection; visit trigger and server cron URL for unreliable WP-Cron. - Pro history and retention: keep the last N backups and/or N days; locked backups and the newest good backup are never removed; off-site copies have their own retention. - Pro off-site storage: Amazon S3 and S3-compatible services (Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces, MinIO); multipart upload, each part retried up to 3 times, resumable; access keys stored encrypted; keep or remove the local copy. - Pro one-click restore: everything, files only or database only, from local or off-site backups; a safety backup of the current site is made first; the database is imported into separate tables and switched over in one step; BackupScope and its settings are not changed; wp-config.php only on request. - Pro email notifications: failures, missed schedules and completed backups; editable templates with preview and test email; works with SMTP plugins. Backup files are never attached. - Pro secure download links in emails: separate download password (never the WordPress password), expire after 48 hours and 3 downloads by default (adjustable 1–168 hours, 1–10 downloads), lock after 5 wrong passwords, HTTPS only, revocable at any time, optional alert email when a link is used. - Pro Storage Analytics: overview of media, plugins, themes, WordPress core, database, stored backups and other folders; tabs with horizontal bars per plugin, theme, folder, database table and file type; largest files; change since previous analysis; worth-reviewing list with a space estimate. Analysing changes nothing. - Pro Safe Cleanup: inactive plugins and themes, other backup archives, cache, temporary files, large logs (emptied with a copy kept). Everything goes to a Cleanup Trash, restorable for 30 days, then removed automatically. The active theme, its parent and one default theme are always kept. - Pro Media review: finds Media Library items with no reference and files in uploads/YYYY/MM not in the Media Library; checks post content, custom fields, page builder data (including Elementor), settings, widgets, every database table and theme files; previews; filters by type and extension; Keep marks. - Licence expiry: nothing is deleted or locked; existing backups stay downloadable and restorable; automation, off-site uploads, updates and support stop until renewal. - Requirements: WordPress 6.2+ (Free), 6.5+ (Pro), PHP 7.4+. ## Pricing - BackupScope Free: $0, on WordPress.org. - BackupScope Pro Solo: 2 sites, $49/year (regular price, also the renewal price). - BackupScope Pro Studio: 5 sites, $99/year (regular price, also the renewal price). - BackupScope Pro Agency: Unlimited sites, $199/year (regular price, also the renewal price). - Launch offer (first year only, until November 30, 2026): Solo $39, Studio $69, Agency $99. From the second year every plan renews at its regular price. - Every Pro plan has the same features; only the number of sites differs. ## Frequently asked questions ### Is BackupScope free? Yes. BackupScope Free makes full WordPress backups of your files and database, verifies them and lets you download them. It is not a trial and has no time limit. ### What does BackupScope Pro add? Scheduled backups, backup history and retention, restore with a safety backup, S3-compatible off-site storage, email notifications with secure download links, Storage Analytics with automatic analysis and capacity alerts, Media review and Safe Cleanup. ### Can I back up both files and the database? Yes. A full backup contains your WordPress files and your database. Or choose areas: database, WordPress core and config, plugins, themes, uploads, other wp-content folders and other root files. ### Does BackupScope support large WordPress sites? Yes. Backups run in small resumable steps, so server time limits do not stop them, and backups above 5 GB use a streaming ZIP64 engine. Your server’s disk space and limits still apply. ### Does BackupScope require mysqldump or cPanel? No. The database is exported through WordPress’s own database connection, and everything runs inside the WordPress dashboard. No cPanel, SSH or mysqldump needed. ### Can I restore a WordPress backup? Restore is part of BackupScope Pro: everything, files only or database only, with a safety backup of the current site first. Every backup is a standard ZIP with a database file, so Free users can restore by hand with our restore guide. ### Can I store backups on Amazon S3? Yes, with BackupScope Pro: Amazon S3 and S3-compatible services such as Cloudflare R2, Backblaze B2, Wasabi and DigitalOcean Spaces. ### Does BackupScope delete files automatically? Cleanup never deletes on its own: you choose what to remove, and it goes to the Cleanup Trash, where it can be restored for 30 days. The one automatic removal is retention in Pro, which removes old backups by the rules you set; locked backups and the newest good backup are always kept. ### What is the Cleanup Trash? A private holding area. Items you clean up are moved there first and can be put back where they were for 30 days. After that they are deleted. ### How does Media review work? It checks your content, custom fields, page builder data, settings, widgets, database tables and theme files, and lists media where no reference was found. It never claims a file is unused: you preview each item and decide. ### Can BackupScope warn me before my storage is full? Yes, with Pro. It analyses storage automatically (daily, weekly or monthly) and emails you when the server disk or your hosting plan limit reaches a warning or critical level. An optional summary email shows the largest areas and the change since the previous analysis. ### What happens if my Pro licence expires? Nothing is deleted or locked. Your existing backups stay available to download and restore. Scheduled backups, off-site uploads, updates and support stop until you renew. ## Documentation - Backup Guide (https://backupscope.pro/docs/backup): How WordPress backups work and how to create your first BackupScope backup. - Restore Guide (https://backupscope.pro/docs/restore): Restore a WordPress site from a BackupScope backup, by hand or with Pro. - Large Site Guide (https://backupscope.pro/docs/large-sites): How BackupScope handles larger WordPress installations. - Storage Guide (https://backupscope.pro/docs/storage): How to understand WordPress disk usage, and what is safe to clean up. ## Changelog ### BackupScope Pro 1.0.0 (2026-10-04) First release of BackupScope Pro. - new: Scheduled backups (daily, weekly, monthly) with full or custom selection, missed-schedule detection, visit trigger and server cron URL. - new: Backup history with lock, download and delete; retention by count and age. - new: Off-site S3-compatible storage with multipart uploads and encrypted credentials. - new: Restore (full, files or database) with an automatic safety backup and atomic database switch-over. - new: Email notifications with editable templates and optional password-protected download links. - new: Storage Analytics with overview chart, tabbed details, largest files and change tracking. - new: Storage monitoring: automatic analysis (daily, weekly or monthly), server disk and hosting plan capacity alerts, and an optional summary email. - new: Growth over time: a chart of how the largest plugins, themes, folders and tables change across analyses. - new: Cleanup of inactive plugins and themes, other backup archives, cache, temporary files and logs, with a 30-day Cleanup Trash. - new: Media review for media with no detected references and stray upload files, with previews, filters and Keep. - new: Runs on its own: the backup engine is built in, so the free plugin is not required. ### BackupScope 1.0.1 (2026-10-03) Restore guide link and engine API for add-ons. - improved: "How to restore manually" now links to the full restore guide. - developer: Engine API 2: jobs with their own step list, used by add-ons. ### BackupScope 1.0.0 (2026-10-03) Initial release of BackupScope. - new: Full Backup (files + database) and Custom Backup. - new: Scan before backup with file count, size and a selectable contents preview. - new: Large sites are backed up step by step; resumable after a refresh. - new: Every backup is verified before it is kept. - new: Private storage, random file names and admin-only downloads. ## Blog ### How Many WordPress Backups Should You Keep? A Simple Retention Plan URL: https://backupscope.pro/blog/how-many-wordpress-backups-to-keep Published: 2026-10-05 Key takeaways: - Keep more than one backup. Problems such as malware or a broken plugin are often noticed days later, after the latest backup already contains them. - A good default: daily backups kept for 7 to 14 days, plus a few weekly or monthly ones. - Never let retention delete the newest good backup, and lock backups taken before big changes. - Keep at least one copy off the server, with its own retention. "We have a backup" often means "we have *one* backup": last night's. That is fine until the problem started three days ago. ## Why one backup is not enough Many problems are not noticed straight away: - **Malware** often sits quietly for days before anyone sees it. - A **broken plugin update** may only break one form or one checkout path. - **Content mistakes**, such as a deleted page or overwritten settings, are found when someone looks for them. If the only backup was taken after the problem started, restoring it brings the problem back. ## A simple plan by site type | Site | How often | Keep | |---|---|---| | Brochure site, rarely changes | Weekly, plus before updates | 4 to 8 weekly backups | | Blog or company site | Daily | 14 daily backups | | Shop or membership site | Daily or more | 14 to 30 daily backups, plus monthly copies | Adjust to how fast your site changes and how much work you can afford to redo. ## Rules that keep retention safe Automatic retention is useful, but it must never remove the backup you need: 1. **Never delete the newest good backup**, even if a rule says it is too old. 2. **Lock important backups**, such as the one taken before a redesign or a major update, so no rule removes them. 3. **Count only successful backups.** A failed backup should never push a good one out. 4. **Off-site copies need their own rule**, often longer than local copies. BackupScope Pro follows these rules: you can keep the last N backups and/or the last N days, locked backups are never removed, the newest successful backup is always kept, and off-site copies have their own retention. In BackupScope Free, the previous backup is deleted only after the new one has been created and verified. ## Storage cost is the trade-off Every kept backup takes space. Exclude caches and old archives from your backups (see [what is using your disk space](/blog/what-is-using-my-wordpress-disk-space)), and keep long-term copies [off-site](/blog/wordpress-backup-to-s3), where storage is cheaper. ## Automate it A retention plan only works if it runs without anyone remembering it. Scheduled backups with automatic retention, and an email when something fails, turn the plan into a routine. FAQ: - Q: Is one WordPress backup enough? A: No. If a problem is noticed after the next backup ran, that backup contains the problem too. Several backups give you a clean point to go back to. - Q: How long should I keep WordPress backups? A: For most sites, two to four weeks of history covers the time it takes to notice a problem. Shops and membership sites may want longer, especially monthly copies. - Q: What is backup retention? A: A rule that removes old backups automatically, for example keep the last 10 backups or the last 30 days, so storage does not fill up. --- ### How to Back Up a WordPress Site: Files, Database and What People Forget URL: https://backupscope.pro/blog/how-to-back-up-a-wordpress-site Published: 2026-10-05 Key takeaways: - A complete WordPress backup has two parts: the files (WordPress, themes, plugins, uploads, wp-config.php) and the database (posts, pages, settings, users, orders). - Take both at the same time, so the files and the database match. - Skip caches, temporary update folders and other plugins' old backups. They make the backup bigger without making it more useful. - A backup you have not checked is a hope, not a backup. Verify the archive and keep a copy off the server. Most WordPress sites are backed up in some form. Far fewer could actually be **restored** from that backup. The gap is usually one of three things: the database was missing, the files and database were taken at different times, or nobody ever checked the archive. ## What a WordPress site is made of A WordPress site lives in two places: - **Files.** WordPress itself (`wp-admin`, `wp-includes`), your themes and plugins in `wp-content`, your Media Library in `wp-content/uploads`, and `wp-config.php`, which holds the database connection settings. - **The database.** Every post, page, comment, setting, user, menu and (on a shop) every order. Usually MySQL or MariaDB. Neither half works without the other. A database without the uploads folder restores posts with broken images. Files without the database restore an empty WordPress install. ## What a full backup should include | Part | Why it matters | |---|---| | Database (all tables) | All content, settings and users | | `wp-content/uploads` | Every image and file in the Media Library | | `wp-content/plugins` and `themes` | Exact versions and any custom code | | `wp-config.php` | Database settings, keys, table prefix | | WordPress core | Lets you restore without a fresh install | | Other `wp-content` folders | Plugin data such as forms, fonts or generated CSS | ## What to leave out Some folders make a backup larger without making it more useful: - **Caches** (`wp-content/cache`, `litespeed`, `et-cache`). Rebuilt automatically. - **Other backup plugins' archives** (`updraft`, `ai1wm-backups` and similar). Backing up backups doubles the size every time. - **Temporary update folders** (`wp-content/upgrade`). - **Version-control and build folders** such as `.git` and `node_modules`. BackupScope excludes these automatically and shows them in the scan, so you can see what was left out and why. ## Take files and database together If the database is exported at 10:00 and the files are copied at 10:40, a post published in between references an image that is in the files but not in the database, or the other way round. Use one tool that does both in one run. ## Check the backup A ZIP that was cut off halfway can still look like a normal file. Before trusting a backup: 1. Make sure it opens and lists its contents. 2. Make sure the database export is there and not empty. 3. Ideally, have every file in the archive read back and its checksum compared. BackupScope does the third step automatically: every entry is read back and its CRC-32 checksum checked, and a backup that fails is discarded so your previous good backup stays in place. ## Keep a copy somewhere else A backup on the same server protects you from bad updates and mistakes. It does not protect you from a failed disk, a hosting account problem or a hacked server. Download a copy regularly, or send copies to off-site storage automatically. BackupScope Pro uploads backups to S3-compatible storage such as Amazon S3, Cloudflare R2 or Backblaze B2. ## A simple routine that works - **Before every update:** a full backup. - **On a schedule:** daily for sites that change daily, weekly for sites that do not. - **Keep several:** not just the latest. A problem is sometimes noticed days later. See [how many backups to keep](/blog/how-many-wordpress-backups-to-keep). - **Test a restore** once, on a staging site, so you know the steps before you need them. The [Restore Guide](/docs/restore) walks through it. Ready to make your first one? The [Backup Guide](/docs/backup) shows each step in BackupScope. FAQ: - Q: Do I need to back up the database and the files separately? A: You need both, but they should be taken together. A tool that backs up both in one run gives you a matching pair, so a restore brings back posts and the uploads they reference. - Q: How often should I back up a WordPress site? A: As often as you can afford to lose work. A busy shop or news site needs daily backups or more; a brochure site that changes monthly can be backed up weekly, plus before every update. - Q: Is a backup on the same server enough? A: No. It protects against mistakes and bad updates, but not against the server failing or the account being compromised. Keep at least one copy somewhere else. --- ### What Is Using My WordPress Disk Space? A Practical Guide URL: https://backupscope.pro/blog/what-is-using-my-wordpress-disk-space Published: 2026-10-05 Key takeaways: - Uploads are usually the largest part, because WordPress creates several resized copies of every image. - Old backup archives, caches and log files are the most common surprise space users, and usually safe to remove. - Inactive plugins and themes take space and can still be a security risk; keep one default theme as a fallback. - Never delete media on a guess. A file can be in use through a page builder, a form or an email. Hosting plans fill up quietly. One day the backup fails for lack of space, or the host sends a warning, and nobody knows where the gigabytes went. ## The usual suspects ### Uploads `wp-content/uploads` is normally the largest folder. For every image you upload, WordPress keeps the original **and several resized copies**, and themes and plugins often register more sizes. One photo can become five to ten files. Videos and PDFs stored in the Media Library add up fast. ### Old backups Backup plugins store archives on the server, often in `wp-content/updraft`, `ai1wm-backups` or similar. Each one can be as large as the whole site. These are frequently the single biggest surprise. ### Caches Page and asset caches (`wp-content/cache`, `litespeed`, `et-cache`) can grow large. They are rebuilt automatically. ### Logs `debug.log` keeps growing while debugging is switched on, sometimes to gigabytes. ### Plugins and themes Inactive plugins and themes still take space, and outdated code can still be a security risk even when inactive. ### Leftovers Interrupted updates leave files in `wp-content/upgrade`. A forgotten staging copy inside the site folder can double everything. ### The database Post revisions, expired transients and log tables written by plugins make the database grow. ## How to see it - **Your host's file manager** usually shows folder sizes, one folder at a time. - **BackupScope Free** scans the site before every backup and shows every area and folder with its file count and size. - **BackupScope Pro** adds Storage Analytics: an overview of media, plugins, themes, core, database and stored backups, tabs with bars per plugin, theme, folder and table, the largest files, the change since the last analysis, and a list of items worth reviewing with an estimate of the space they could free. ## What is usually safe to clean up - Caches, from your caching plugin. - Old backup archives from other plugins, after downloading anything you still need. - Inactive plugins and themes you no longer use. Keep your active theme, its parent and one default theme. - Large log files, after switching off debug logging. - Temporary update files, when no update is running. ## Be careful with media The most common cleanup mistake is deleting media that "looks unused". A file can be linked from a page builder layout, a form's confirmation email, a widget, a theme file or another site. BackupScope Pro's Media review checks content, custom fields, page builder data (including Elementor), settings, widgets, every database table and theme files before it lists anything, and lets you preview each file. Even so, nothing can see links from outside your site, so when in doubt, keep it. ## Clean up with a way back Whatever you remove, make it undoable. BackupScope Pro's Cleanup moves items to a Cleanup Trash, where they can be restored for 30 days. And take a backup first: the [Backup Guide](/docs/backup) shows how. For more detail, read the [Storage Guide](/docs/storage). FAQ: - Q: Why is my WordPress uploads folder so large? A: Every uploaded image is stored several times in different sizes, and many themes and plugins add their own sizes. Large originals, videos and PDFs add up quickly too. - Q: Is it safe to delete the wp-content/cache folder? A: Usually yes: caching plugins rebuild it automatically. Clear it from the caching plugin's settings rather than deleting files by hand while the site is busy. - Q: How do I find unused images in WordPress? A: Look for media with no reference in posts, custom fields, page builder data, settings, widgets, other tables and theme files. Review each one before removing it, and keep a way to undo. --- ### Why WordPress Backups Fail on Large Sites (and How to Fix It) URL: https://backupscope.pro/blog/why-wordpress-backups-fail-on-large-sites Published: 2026-10-05 Key takeaways: - Most large-site backup failures come from doing too much in one PHP request: the request hits max_execution_time or the memory limit. - A reliable backup works in small, resumable steps that each finish well within the time limit and continue where the last one stopped. - Archives over 4 GB need the ZIP64 format; streaming the archive in batches avoids building it in one go. - Database exports should page through tables and split very large values, so they work without mysqldump and import with a default max_allowed_packet. A backup that works perfectly on a 300 MB site can fail every time on a 20 GB one. The plugin is not broken. It is running into limits that small sites never reach. ## The four usual causes ### 1. PHP time limits Every PHP request has a `max_execution_time`, often 30 to 120 seconds on shared hosting. Zipping gigabytes of uploads in a single request does not fit, so the request is killed and the backup stops. ### 2. Memory limits Building an archive or a database export in memory needs memory proportional to its size. Large sites run out. ### 3. No mysqldump Many hosts do not allow running command-line tools from PHP. A backup that relies on `mysqldump` either fails or silently skips the database. ### 4. One oversized row A single huge value, such as a serialized page builder layout or a log stored in the database, can exceed MySQL's `max_allowed_packet` when the export is imported again. The backup "works", but the restore fails. ## What works instead: small, resumable steps The fix is to stop treating a backup as one long operation: - **Split the job into steps** (scan, database, archive, verify), and each step into small slices that finish well inside the time limit. - **Save the position after every slice**, so the next request continues where the last one stopped. A server restart or a closed browser tab no longer means starting over. - **Lock the job** so two requests never write to the same backup at once. This is how BackupScope runs every backup, small or large. The [Large Site Guide](/docs/large-sites) explains the details. ## Archives over 4 GB: ZIP64 and streaming The classic ZIP format cannot describe files or archives larger than 4 GB. **ZIP64** removes that limit and is supported by all current unzip tools. Building a huge archive in one pass is also where many backups run out of time. A **streaming** writer adds files in batches across many requests instead. BackupScope estimates the size during the scan: up to 5 GB it builds a standard ZIP, above that it streams a ZIP64 archive in batches, and if the standard path fails it falls back to streaming automatically. The 5 GB value only chooses the engine; it is not a size limit. ## Database exports that survive large tables A robust export: - reads each table **page by page** instead of all at once, - writes **very large values in chunks**, so the import works with a default `max_allowed_packet`, - exports binary and BIT columns in a form MySQL reads back exactly, - runs through WordPress's own database connection, so no `mysqldump` is needed. More on that in [WordPress database backups without mysqldump](/blog/wordpress-database-backup-without-mysqldump). ## Practical tips for large sites - **Check free disk space first.** The server needs room for the archive, roughly the estimated backup size. - **Leave out what is not needed.** Caches and other plugins' backup folders should never be in a backup. Untick large folders you already keep elsewhere. - **Verify the result.** Large archives are exactly where truncation goes unnoticed. - **Upload in parts.** For off-site copies, multipart uploads mean an interrupted upload does not start from zero. A large site is not a reason to give up on reliable backups. It just needs a backup that was built for it. FAQ: - Q: Why does my WordPress backup stop at the same percentage every time? A: It is usually hitting a server limit at the same point: PHP's max_execution_time, the memory limit, or a single very large file or database row. A backup that works in small resumable steps avoids all three. - Q: Is there a maximum backup size for WordPress? A: Not in WordPress itself. The practical limits are your server's free disk space, PHP limits and your host's file size limits. ZIP64 removes the old 4 GB ZIP limit. - Q: Does a large site need a different backup plugin? A: It needs one designed for large sites: resumable steps, a streaming archive for big backups, and a database export that does not depend on mysqldump. --- ### WordPress Backup to S3: Amazon S3, Cloudflare R2, Backblaze B2 and Wasabi URL: https://backupscope.pro/blog/wordpress-backup-to-s3 Published: 2026-10-05 Key takeaways: - A backup on the same server does not survive a server failure or a compromised account. Keep a copy off-site. - Amazon S3, Cloudflare R2, Backblaze B2, Wasabi and DigitalOcean Spaces all speak the same S3 API, so one integration works with all of them. - Use a bucket and access key just for backups, with only the permissions the backup needs. - Large backups should be uploaded in parts (multipart upload) so an interruption does not start over. The most common way to lose a WordPress site with "backups" is to keep every backup on the same server as the site. When the disk fails, the hosting account is suspended or the server is compromised, the backups go with it. ## Why S3-compatible storage "S3" started as Amazon's storage service, but its API became the standard. Today many providers speak it: - **Amazon S3** - **Cloudflare R2** - **Backblaze B2** - **Wasabi** - **DigitalOcean Spaces**, and self-hosted options such as **MinIO** Because they share the API, a backup tool that supports S3 can send backups to any of them with an endpoint, a bucket name and an access key. ## What to compare between providers Pricing changes, so check each provider's current page, but compare the same things: - **Storage price** per GB per month. - **Download (egress) charges.** You pay these when you restore. Some providers charge nothing or little for egress. - **Request charges** for uploads and listings. - **Minimum storage duration.** Some providers bill deleted files for a minimum period. - **Region**, for data-protection requirements and restore speed. ## Set it up safely 1. **Create a bucket just for backups.** Keep it private. 2. **Create an access key just for this bucket**, with permission to upload, list, download and delete in that bucket and nothing else. 3. **Store the key securely.** BackupScope Pro stores access keys encrypted in the database. 4. **Never make backup files public.** A WordPress backup contains `wp-config.php` and your whole database. ## Upload large backups in parts A single multi-gigabyte upload is fragile on ordinary hosting. **Multipart upload** splits the archive into parts that are uploaded separately and joined by the storage service. If one part fails, only that part is sent again. BackupScope Pro uploads large backups this way, retries each part up to three times and resumes after an interruption. ## Decide what happens to the local copy Keeping the local copy gives you a fast restore; removing it saves disk space. BackupScope Pro lets you choose, and off-site copies follow their own retention rule. See [how many backups to keep](/blog/how-many-wordpress-backups-to-keep). ## Test a restore from off-site An off-site backup is only useful if you can get it back. Once, download a backup from your bucket and restore it on a staging site. The [Restore Guide](/docs/restore) covers both a manual restore and one-click restore in Pro. FAQ: - Q: Which S3-compatible storage is best for WordPress backups? A: All the major ones work. Compare price per GB stored, request and download (egress) charges, the regions on offer and minimum storage durations against how often you back up and restore. - Q: Are WordPress backups in S3 safe? A: Keep the bucket private, use a dedicated access key with limited permissions, and store that key encrypted. Never make the bucket or the backup files public. - Q: Can I restore directly from S3? A: With BackupScope Pro, yes: one-click restore can fetch a backup from off-site storage. Without it, download the archive and restore by hand. --- ### WordPress Database Backups Without mysqldump: How It Works URL: https://backupscope.pro/blog/wordpress-database-backup-without-mysqldump Published: 2026-10-05 Key takeaways: - You do not need mysqldump to back up a WordPress database. It can be exported through WordPress's own database connection. - Export tables page by page using the primary key, so memory stays flat and no request runs too long. - Split very large values into chunks so the file imports with a default max_allowed_packet. - Handle binary, BLOB and BIT columns explicitly, or the restored data will not match. `mysqldump` is the classic way to export a MySQL database. On a lot of WordPress hosting it is simply not available: PHP is not allowed to run command-line programs. A backup that depends on it either fails or quietly leaves the database out. ## Exporting through PHP WordPress already has a database connection. A backup can use it to read each table and write a standard SQL file: `CREATE TABLE` statements followed by `INSERT`s. The result imports anywhere a normal dump would. The hard part is doing that safely on real sites. ## Page through tables Selecting a whole table at once loads it into memory. On a table with millions of rows, that fails. Instead: - read rows in **pages ordered by the primary key** ("keyset pagination"), - remember the last key, and continue from there in the next request. Memory stays flat no matter how large the table is, and the export can stop and resume between requests. ## Keep statements under max_allowed_packet MySQL rejects any single statement larger than `max_allowed_packet` (often a few megabytes by default). If an export writes one `INSERT` for a row holding a 20 MB serialized value, the backup looks fine but **the import fails**. The fix is to write very large values in chunks: insert the row with the start of the value, then append the rest with `UPDATE … SET col = CONCAT(col, …)` statements. Every statement stays small, and the restored value is identical. ## Binary and BIT columns Some columns cannot be written as plain text: - **BLOB / BINARY** data must be written as hexadecimal literals. - **BIT** columns must be written as numbers, or they come back wrong. - **Geometry** columns are binary too. Getting these wrong produces a backup that imports without errors and still corrupts data. ## How BackupScope does it BackupScope's exporter works through WordPress's own connection, pages through tables by key, writes large values in chunks so imports work with a default `max_allowed_packet`, and handles binary and BIT columns explicitly. The export runs in resumable steps, like the rest of the backup, and ends with a footer so a truncated file is detected. Read more in the [Large Site Guide](/docs/large-sites). ## Restoring the export The file is plain SQL. Import it with phpMyAdmin, Adminer, or for large files the command line: ``` mysql -u USER -p DATABASE_NAME < database.sql ``` The [Restore Guide](/docs/restore) covers the full process, including what to change if the domain moved. FAQ: - Q: Can I back up a WordPress database without phpMyAdmin or mysqldump? A: Yes. A backup plugin can export every table through PHP using WordPress's database connection. The result is a normal .sql file you can import with phpMyAdmin, Adminer or the mysql command. - Q: What is max_allowed_packet and why does it matter for backups? A: It is the largest single statement MySQL accepts. If a backup writes one huge INSERT for a big row, importing it fails. Writing large values in chunks keeps every statement under the limit. - Q: Is a PHP database export slower than mysqldump? A: It can be, but done in pages it is predictable and works on hosts where mysqldump is not available at all, which matters more than raw speed.