Integration for Google Drive includes a complete Backup, Restore, and Migration system. It copies your WordPress database and site files into a single archive, stores that archive on your server and/or in your Google Drive account, and can rebuild your website from any of those copies — on the same host or on a completely different one, without FTP.

This guide covers the whole feature: what is included in a backup, how to create and schedule backups, where they are stored, how to restore, and how to move a site between hosts.

Backup & Restore is a Pro feature, introduced in version 1.4.7. On the free version the Backups screen shows a preview with an upgrade prompt. Only administrators (users with the manage_options capability) can open or use it.

Where to Find the Backups Screen

In your WordPress dashboard, go to Google Drive → Backups.

The screen opens on the All Backups dashboard and has its own sidebar, grouped into two sections:

• Backup — All Backups, Schedules, Migration, Transfer
• Storage — Google Drive, Local Storage

The + New Backup button sits in the top bar rather than in the sidebar, next to a Restore shortcut.

You do not need a connected Google account to use backups. Without one, archives are simply kept on your own server, where you can still download them, share them by link, and restore from them.

What Gets Backed Up

You choose which parts of the site to include. All five components are selected by default:

What Is Not Included

This is a backup of your site’s content, not a full server image. The following are deliberately left out:

• WordPress core files — wp-admin, wp-includes, and the PHP files in the site root. These are identical for every WordPress site and can be reinstalled at any time.
• Your wp-config.php — it holds database credentials specific to each server, so it is never captured and never overwritten during a restore.
• Database tables belonging to a different table prefix, if you share one database between several sites.
• Symbolic links.

Practically, this means restoring onto a brand-new server requires a working WordPress installation to restore into — see Migration below.

What Is Skipped Automatically

To keep archives small and reliable, the following are always excluded:

• The plugin’s own backup folder, so backups never nest inside each other
• The cache and upgrade folders, and debug.log
• Developer and build directories anywhere in the tree: node_modules, bower_components, .git, .svn, .hg, .idea, .vscode, .cache, .sass-cache, .next, .nuxt, .parcel-cache, vendor-bin, __pycache__
• Junk files: .DS_Store, Thumbs.db, *.tmp, *.swp, and editor backups ending in ~

Ordinary files in your uploads folder are always preserved, including ZIP, SQL, and archive files you uploaded yourself — for example downloadable products.

Creating a Backup Manually

1. Go to Google Drive → Backups and click + New Backup.
2. Enter a Backup Name. This is optional — leave it empty and the backup is named Backup YYYY-MM-DD.
3. Under What to Include, tick the components you want. At least one is required before the button becomes active.
4. Optionally turn on Upload to Google Drive and choose a destination folder. Leave the folder unset to use the default Integration Google Drive Backups folder.
5. Decide whether to Keep a local copy on this server after the upload. This is on by default; turning it off frees disk space once the upload succeeds.
6. Click Create Backup.

You are returned to the All Backups dashboard, where the progress card takes over.

Only one job runs at a time. While a backup or restore is in progress the form is disabled and you will see “Another backup or restore is currently running.”

Watching a Backup Run

While a job is active, a progress card shows the percentage complete, elapsed time, an estimated time remaining, and a live detail line such as “3,214 of 13,875 files” or “12 of 48 tables”. A chip for each selected component turns green as it finishes.

A backup moves through these stages:

1. Scanning files — building the file list
2. Exporting database — writing the SQL dump
3. Building archive — packing everything into one archive
4. Validating archive — verifying the archive is complete and readable
5. Uploading to Google Drive — only when Drive upload is enabled

You can stop a running job at any time with Cancel; partial files are removed automatically.

Why You Should Keep the Tab Open

Backups run as a series of short background passes rather than one long request, so a PHP timeout can never break them — each pass saves its position and the next one picks up exactly where it left off. Three mechanisms keep a job moving: a background loopback request, a WordPress cron fallback, and the Backups screen itself.

On hosts that block background requests, the open browser tab becomes the driver. The progress card then warns you: “Your server is blocking background requests, so this tab is driving the backup — keep it open and in the foreground.” If you navigate away the job pauses, and it resumes when you reopen the screen. A job that makes no progress for 10 minutes is marked as stalled.

Scheduling Automatic Backups

Go to Backups → Schedules. Scheduled backups are off by default.

1. Turn on the schedule switch.
2. Pick a Frequency: Hourly, Twice daily, Daily (default), or Weekly.
3. Choose which components to include — all five by default.
4. Optionally enable Upload to Google Drive, pick a folder, and choose whether to keep the local copy.
5. Click Save Schedule.

The page then shows the next run and last run times. You can also switch scheduled backups on and off directly from the All Backups dashboard, which saves immediately.

Each automatic backup is named Scheduled backup followed by its date and time. If a backup or restore is already running when the schedule fires, that run is skipped. If Drive upload is enabled but no Google account is connected at that moment, the backup still runs and is kept locally.

Requires working cron. Scheduled backups rely on WordPress cron, which needs regular site traffic or a real system cron job. If your site defines DISABLE_WP_CRON, a red warning appears and scheduled backups will not run until a real system cron triggers wp-cron.php.

Where Backups Are Stored

Local Storage

Archives are written to a protected folder inside your uploads directory, guarded against direct web access. The Local Storage page lists every backup and restore record with its status, size, and date, plus badges showing whether a copy exists on this server, in Google Drive, or both.

Google Drive

When Drive upload is enabled, the archive is uploaded in resumable chunks to an Integration Google Drive Backups folder, inside a subfolder named after your site’s domain — so several sites, including local development sites, stay neatly separated. Each file is tagged so the plugin can recognise it later.

The Google Drive page lists backups from every website connected to that Google account, grouped by source site. That is what makes cross-site migration possible. The list shows up to 500 archives.

There is no automatic retention or clean-up. Old backups are never deleted for you. Review your Local Storage list and your Drive folder periodically and remove archives you no longer need, or you will eventually fill your disk or Drive quota.

Managing Existing Backups

Each completed backup offers these actions, from the Local Storage list or the ⋮ menu on the dashboard:

• Restore — rebuild this website from the backup.
• Download — save the archive to your computer.
• Copy Link — copy a secure download link, valid for 3 days, that another site can import.
• Upload to Drive (or Re-upload to Drive) — send an existing local backup to Google Drive after the fact. The local copy is always kept in this case.
• Delete — permanently remove the local archive and its record.

Deleting a backup removes the local file only. Copies already uploaded to Google Drive are kept, and must be deleted from Google Drive yourself.

Restoring Your Website

You can restore from four sources:

Every restore asks you to confirm first, because a restore is destructive:

This will overwrite this website’s database and files with the backup contents. This cannot be undone. You will need to log in again after the restore finishes.

How a Restore Works

A restore is deliberately cautious. Rather than unpacking straight over your live site, it works through these stages:

1. Downloading the archive, in resumable chunks
2. Validating it, confirming it was made by this plugin and that there is enough free disk space
3. Extracting it into a separate staging folder
4. Importing the database into temporary tables, so your live site keeps working throughout
5. Updating URLs and paths to match this site
6. Restoring files from the staging folder
7. Activating the restored data by swapping the temporary tables into place

Because URLs and paths are rewritten in step 5, a backup taken on one domain restores correctly onto a different domain — this is what makes live-to-local and local-to-live migration work. Serialized data is handled safely, so widget settings, theme options, and page-builder content survive the change of address.

Two things are protected and never overwritten: your wp-config.php, and the Integration for Google Drive plugin itself (the code performing the restore). Your existing backup history is also preserved rather than replaced by the source site’s.

When the restore finishes you are asked to reload wp-admin and log in again, because the user accounts and sessions now come from the backup.

There is no undo. The plugin does not put your site into maintenance mode during a restore, and it cannot roll a completed restore back. Always take a fresh backup of the destination site before restoring over it.

Import Speed

The Migration, Transfer, Google Drive, and Local Storage pages each offer a speed setting controlling how much work each restore pass does:

• Safe · smaller chunks — shorter, gentler requests for strict shared hosting, or when a restore keeps stalling
• Balanced · recommended — the default
• Fast · larger chunks — fewer, longer requests; quicker on capable servers, but more likely to hit a host’s timeout or memory limits

This setting affects restores and imports only. It never changes how a backup is created.

Migration: Moving a Site Between Environments

Open Backups → Migration to rebuild this website from a backup made elsewhere. This is the live-to-local and local-to-live workflow, and the two sites do not need to share a Google account.

Three options are available:

• Restore from Google Drive — pick any backup in the connected account, from any site, and click Restore Here.
• Restore from URL — paste a download link copied from another Integration for Google Drive site.
• Restore a local backup — reuse a backup already stored on this server.

Migrating to a New Host, Step by Step

Because backups do not contain WordPress core or wp-config.php, the destination needs a working WordPress install to restore into:

1. On the source site, create a full backup (all five components).
2. On the source site, open Backups → Transfer and click Copy Link for that backup — or Download the archive if you prefer to move the file yourself.
3. On the destination server, install a fresh copy of WordPress and connect it to its own database.
4. Install and activate Integration for Google Drive Pro on the new site.
5. Open Backups → Migration, paste the link under Restore from URL, and confirm. If you downloaded the archive instead, use Backups → Transfer and upload it there.
6. When the restore completes, reload wp-admin and log in with the source site’s credentials.

Transfer: Moving a Site Without FTP

Open Backups → Transfer to move a site between hosts using only the WordPress dashboard.

Upload a Backup File

Click Choose Backup File and select an Integration for Google Drive backup archive from your computer. After you confirm the restore warning, the file uploads in small chunks with a progress bar, and the restore starts automatically. You can abort mid-upload with Cancel Upload, which deletes the partial file from the server.

Share a Download Link

For any backup stored on this server you can Copy Link or Download the archive. The link is cryptographically signed and expires after 3 days. Downloads support resumable range requests, so even very large archives transfer reliably and can be paused and resumed.

Housekeeping: Leftover Restore Files

Restores unpack data into temporary staging folders. If a restore is interrupted, those files can stay on disk. When that happens, an information banner appears on the All Backups and Migration pages showing how many items are left over and how much space they use. Click Clean Up to delete them — your actual backups are not affected.

Requirements and Technical Details

• Archive format: a standard ZIP when PHP’s ZipArchive extension is available. If it is not, the plugin transparently builds its own streaming archive with an .igda extension instead. Files that are already compressed — images, video, audio, PDFs, existing archives — are stored without wasteful re-compression.
• Restoring a ZIP archive requires the ZipArchive extension on the destination server. Archives in the .igda format can be restored anywhere.
• Database export: uses the server’s mysqldump when it is available, and otherwise falls back to a built-in, resumable PHP exporter that writes 1,000 rows at a time. No special server tools are required either way, and very large tables cannot time out.
• Every archive carries a manifest recording the plugin and WordPress versions, site URLs, paths, database prefix and character set, the table list, the PHP version, and the file count and size. Archives without it are rejected on restore.
• Disk space: a backup needs room for the archive plus a temporary database dump. A restore checks free space before extracting and stops with a clear message if there is not enough. There is no such check before a backup, so keep an eye on available space.
• Permissions: PHP needs write access to your uploads directory, and to the whole WordPress directory when restoring.
• Security: download links are signed with a key derived from your site’s own secret salts and expire automatically. The backup folder is protected against direct web access, and archives are checked for unsafe paths during extraction.
• Not supported: WP-CLI commands, splitting an archive into multiple parts, excluding individual files or database tables from the interface, and automatic deletion of old backups.

Troubleshooting

“Scheduled backups will not run”

Your site has DISABLE_WP_CRON enabled. Add a real system cron job that calls wp-cron.php at a regular interval, or remove the constant.

The backup stalls, or stops when I close the tab

Your host is blocking loopback (background) requests. Keep the Backups tab open and in the foreground until the job finishes. Reopening the screen resumes a paused job.

“Could not load Google Drive backups”

No Google account is connected, or the connection has expired. Go to Settings → Accounts and connect or re-authorise your account.

The restore keeps failing or timing out

Set Import speed to Safe · smaller chunks and start the restore again. This lowers memory use and shortens each processing pass.

“This archive requires the ZipArchive PHP extension to restore”

The destination server is missing PHP’s zip extension. Ask your host to enable ext-zip, then start the restore again.

“Not enough disk space to extract this backup”

A restore needs room for both the archive and its extracted contents at the same time. Free up space, or delete old local backups first.

“Another backup or restore is currently running”

Only one job can run at a time. Wait for the active job to finish, or cancel it from the progress card.

The website isn’t responding during a backup

The progress card keeps the last known state and retries automatically with increasing delays. Leave the tab open — the job resumes on its own once the site is reachable again.

Frequently Asked Questions

Do I need a Google account to use backups?
No. Without one, backups are stored on your server and can still be downloaded, shared by link, and used to restore or migrate.

Does a backup include WordPress itself?
No. WordPress core files and wp-config.php are excluded, because they are server-specific or freely reinstallable. Install WordPress first, then restore into it.

Are old backups deleted automatically?
No. There is no retention limit, so remove archives you no longer need.

Can I restore a backup onto a different domain?
Yes. URLs and file paths are rewritten during the restore, which is exactly how migration between environments works.

Does deleting a backup also delete the Google Drive copy?
No. Only the local file is removed; the Drive copy stays until you delete it in Google Drive.

How long does a download link stay valid?
Three days from the moment it is created.

Will my site stay online during a backup?
Yes. Backups only read your data and run in short background passes. A restore, however, replaces your database and files, so treat it as downtime.

Can I back up only some files or tables?
You can choose any combination of the five components. Finer-grained selection is not available from the interface.