Honest answers about how GWS Backup works.
Yes, for up to 10 client workspaces. GWS Backup is free under the GWS Backup Free Licence, for personal and commercial use alike — including MSPs serving paying clients. No trial clocks, no feature withheld. Above 10 workspaces is by enquiry.
Development is funded by voluntary donations.
No — same software, same features, same limit. A donation buys the time to keep building this, and we’ll say thank you personally.
Need more than ten workspaces? That’s a separate conversation, not a donation.
No. GWS Backup is free to use, but not open source. You may not rebrand, resell or redistribute the software.
If you'd like it under your own brand legitimately, that's what our white-label programme is for.
Yes — commercially. You can purchase GWS Backup as a white-label product sold under your own identity, or for a one-off fee we'll fit your logo and colours into the app for you.
Use the contact form with details of your business and we'll come back with a straightforward quote.
Version 1.00 is out now, for cPanel and Linux, Windows and Docker: the first full release after the betas. The download page offers the current version, and updates never touch your licence or settings.
From 1.00 you no longer need to come back here for updates. The console tells you when one is out and, on cPanel and Windows, installs it when an Admin clicks Install update.
Releases are announced on the development roadmap.
For the free edition, please allow 1–2 days for a response. For white-label and custom-branded packages, enquiries are usually answered the same day (UK time).
Download the release files, create a Node.js application in cPanel — Setup Node.js App or Application Manager, whichever your host provides (Node.js 22.13 or newer), upload and extract the files into the application root, and activate your free licence key on first run.
The full step-by-step walkthrough lives on our Install Guide, and a README with the same instructions is included inside the download.
Never inside public_html. The application folder contains your encrypted credentials database and encryption keys — those files must not be web-accessible. Install into a folder in your home directory instead (e.g. ~/gwsbackup).
We also strongly recommend serving it on a subdomain with a random, unguessable name — vault-k7x93q.yourdomain.com rather than backup.yourdomain.com.
Yes. GWS Backup will not run without a licence key: the first-run setup asks for it and goes no further until a valid one is entered.
Keys are free. Fill in the short form on the home page (Get your licence key) and choose 1–10 workspaces. We will endeavour to send your key automatically, with the download and install links. If it is not there within a few minutes, check your spam folder.
If our system detects an issue with the details entered, such as a second address at a company that already has a key, we’ll contact you directly to confirm the submission, usually within 48 hours. For more than ten workspaces, choose that size on the same form and we’ll reply to talk it through.
Lost your key? Register again with the same email address and the same key is sent again.
Validation requires the server to have outbound internet access, and each key permits one running installation at a time.
A cPanel account that can run a Node.js application — either Setup Node.js App (CloudLinux Node.js Selector) or Application Manager (cPanel’s own); which one you get is decided by your host. Then Node.js 22.13 or newer (required for the built-in SQLite engine), PHP with ZipArchive for the update script, and outbound HTTPS access.
The app needs about 100 MB of disk. Memory depends on how many backups run at the same time, not on how many workspaces you have: the console allows about 1 GB for each backup running at once and queues the rest. Your backup data itself is stored in your destination — Google Drive, S3, Azure or local disk — not on the web server.
On a small server (2 GB of memory or less) backups run one at a time. To back up as many as ten workspaces there, give each its own start time, an hour or more apart (in its Settings, under Schedule), so each finishes before the next is due, and run each new workspace’s first full backup on its own.
Upload the new release zip and its matching installer into your application folder, then run the installer — for example php gwsbackup-cpanel-1.00-installer.php. It backs up your databases first, then extracts the new build — your data, licence and settings are untouched. Restart the app in cPanel afterwards.
From 1.00 you do that once. When a newer version is out, the console says so in the sidebar, which opens Settings → System, under Updates. On cPanel and Windows, an Admin clicks Install update: it waits until no backup or restore is running or waiting, backs up your databases, installs the update and restarts. On cPanel, if the new version does not start, the one before it is put back by itself. On any other Linux server it points you to the download page.
On Docker, update from the folder that holds docker-compose.yml: set GWSB_VERSION= and the new version number in its .env, then run docker compose pull and docker compose up -d. A compose file downloaded before 1.00 names its version on its image: line instead: change the number at the end of that line. The console shows this too, with the new version filled in.
New releases are announced on the blog, and the feature list always reflects the current version.
Run the newer installer over the top. Clients, schedules, history and your encryption key all survive. It will ask to restart.
From 1.00, later updates install from the console: an Admin clicks Install update when it offers one, and Windows does not need restarting. The port is set in C:\Program Files\GWSBackup\.env, not in Settings.
The console walks you through the first part itself, one step at a time: your account and its recovery key, then the keys, the licence, the agreement, where backups go and your first client. You can leave the last two for later. If you sign out half way, it picks up at the right step.
After that, Overview shows Admins a short setup checklist until everything on it is done. Work down it in order:
Two things the checklist does not ask for:
There is nothing to switch on for the console's own database: it is backed up every night, encrypted, to your destination, from the moment one is set up.
After that the app runs itself. Look at Overview now and then: Needs attention lists any client whose backup failed, was stopped or has not worked for two days.
The first run for a client indexes every email, file and calendar event from the beginning of time and downloads all of it. For a mailbox with years of history that is genuinely hours of work, and it is bounded by how fast Google will hand the data over, not by your server.
Every run after it is incremental: the app checks what has changed since last time and only downloads that. A typical daily run finishes in minutes, even for a client whose first run took most of a day.
If a first run is interrupted — a restart, a crash, Google's daily limit — nothing is lost. It continues from where it left off rather than starting again: by itself after a restart, or at the next run after a pause.
Three things, all on the client's side:
The client's Connect page walks through each part: the APIs to switch on in their Google Cloud console, the key to paste (checked as you paste it), and the Client ID and scopes to copy into their Google Admin console. Its Test signs in as that Super Admin, checks the permissions backups need, and says what Google said about any that fails. The extra permissions a restore needs are checked when you start a restore of a whole account or the workspace. If delegation is missing or incomplete you will see unauthorized_client — see the troubleshooting section.
The licence is free and does not expire. What it limits is not features but use: one running installation per key, no reselling or redistributing the software, and no rebranding it as your own product.
You may use it commercially — including running backups for your own paying clients as a managed service. That is explicitly allowed.
The number of workspaces you can protect comes from your key. If you hit the limit, adding a client is refused with a message naming the cap.
Every client counts towards it, including archived ones and ones not yet connected. To free a place, delete an archived client: open its Settings and click Delete…. Only an Admin can do that.
The console shows every time by the server's clock, because that is the clock schedules run by. A server in another time zone shows its own times, on every page and in the restore dialog. Set the server's time zone to yours if you want them to match.
For every item it compares what Google reports against what is already in the backup index. Unchanged items are skipped without downloading anything.
A run starts fresh rather than incremental in three cases: the client has never been backed up, the backup destination was changed, or someone chose Full backup… under More on the client's Status page. A fresh run copies everything again, and the runs after it are incremental. If the client's folder has gone missing from a Google Drive destination, the run stops and says so, rather than quietly starting again from nothing.
A file that has only been moved in Drive is re-pointed in the index, not downloaded again.
Paused means Google has stopped it for the day, not that it failed. Nothing has been lost and nothing needs redoing — the run stops cleanly, records exactly what it had finished, and picks up from there.
A backup pauses when Google's daily quota runs out, or when Google keeps refusing after repeated retries. The next scheduled run carries on from where it got to. On a local-folder destination a backup also pauses, rather than failing half way, when the disk is nearly full.
A restore is usually paused by Google's per-user transfer cap: 750 GB of upload per account per 24 hours, counted across My Drive and all shared drives, and it includes copies. Unlike the API quota, Google states this cap cannot be increased and cannot be requested — waiting is the only option. A paused restore resumes by itself once the window passes (up to five times for one restore), and you can always resume it by hand from the client's Restore page.
If you need a restore finished sooner, the cap is per user, so splitting the work across several target accounts multiplies your real throughput — three targets means three separate 750 GB allowances. For a whole account or the whole workspace, the restore dialog (under More on the restore bar) estimates this before you start.
What will not help: routing the transfer through another machine or rotating service accounts and projects. The cap is enforced against the target account whatever the traffic's origin, and rotating credentials to dodge it puts the customer's Workspace at risk.
No. Google limits how fast anyone can pull data out. When the app hits a rate limit, it waits a calculated cooldown (exponential backoff) and tries again, at least six times, before it pauses the run for the day. A 503 or a dropped connection is retried the same way, up to four times. If it still fails, that one item is listed as an error, the run moves on, and the next run tries it again. No data is lost and no run needs restarting. Seeing these in a log is normal for a large backup.
You can raise this one yourself. The per-minute limit is a quota on your Google Cloud project — 1,000,000 quota units per minute per project and 325,000 per user by default — and it is adjustable, free, from the Cloud console under IAM & Admin → Quotas & System Limits (search for the Drive API). Approval is not guaranteed, but for a busy console it is the single most effective change you can make.
This is not the same as the 750 GB per-user daily transfer cap, which cannot be raised. See the question about runs paused by Google's daily limit.
No — not for a year, and never because Google says so. That is the entire point of a backup.
The app records when the item stopped existing in Google, so you can tell "still in Google" from "only exists in the backup now".
After 365 days the backup of a deleted item can be removed for good. The 365 days are fixed in the software: nobody can change them. Until then it is fully restorable, and while a client is archived nothing of it ages out at all.
Whether it is removed is set on Settings → Retention, under Deleted items. Turning removal on first shows what the first pass would remove, and asks you to agree. Only an Admin can change it. New installs start with removal on. An install updated from an earlier version keeps deleted items for ever until an Admin turns removal on.
This applies to mail as well as Drive, on every destination — with safety checks so an incomplete listing can never wrongly mark live items as deleted.
A large binary is downloaded as a single stream. Progress is reported per item, so a 2 GB video looks like a stall until it completes and the counter jumps.
A run is only stuck if nothing at all moves for five minutes. The client's Status page then says No progress for…. Within a couple of minutes the app stops that run by itself (it shows as Stopped) and starts one that carries on from where it got to. What was copied is kept.
It carries on by itself as soon as the app is back, skipping what was already copied. Nothing that was already backed up is lost, and nothing is duplicated. The cut-off run shows as Interrupted, and Activity shows the new one as started by System.
It is not carried on by itself when the client is suspended or archived, every schedule is paused (Pause all under Scheduled backups), or a restore of that client is under way. The next run that is allowed carries on from where it got to. It also waits for its next scheduled run after three separate stops in one day (restarts within half an hour count as one), or after six carry-ons in a day however they fall, so a server that keeps falling over does not go round in circles.
A scheduled time missed while the app was down runs once, when it is back. On cPanel, the installer adds a small cron job so that the host's nightly web-server restart does not leave the app stopped until someone opens a page.
Shared drives, yes. Each one is backed up alongside the accounts, and the client's Status page shows when each was last backed up. A shared drive restores the same way as a user account, with one difference: because a shared drive is not a person, restoring it always needs an account to write into.
Groups have no backup of their own. Mail sent to a group is backed up in the mailboxes it is delivered to, as part of those accounts. A conversation that lives only in the group itself, such as a collaborative inbox that sends its members no email, is not backed up.
Group inboxes backed up by versions before 1.00 are still on the client's Restore page, under Group inboxes. Select the messages you need and choose an account under Restore into: a group inbox is restored message by message, not whole.
On the client's Restore page, choose the backup under Restore from, find the items by account, kind or search, and tick them. They stay ticked while you move between pages, accounts and kinds.
Under Restore into, leave Their own accounts or pick another account, then click Restore. Each item is restored straight away and shows Restored, or why it failed, under its name. Anything that failed stays ticked, so you can try again.
Items from a shared drive, or from an account that is deleted or suspended, need an account to go into. A whole account or the whole workspace is restored from More on the restore bar instead.
Yes, for Drive files. Each backup keeps the previous copy of anything that changed, so a file that has been edited several times has several stored versions. On the client's Restore page each file shows how many versions are kept; click the number to pick one by the date it was captured and restore that one. It opens on the version that was current at the backup chosen in Restore from, which is the newest unless you pick an older backup.
You can also roll back in bulk — a whole workspace, one account, or one part of it such as Drive or mail — to how it stood at a chosen backup. Choose the backup in Restore from, and for one account choose it in the list beside it. Then click More on the restore bar.
Two limits worth knowing:
Restoring an older version adds it beside what is in the account now. Files and mail come back as extra copies, and nothing live is deleted. Two exceptions: a calendar event that is still there is updated to how it was at that backup, and an Admin can choose to empty the account first (see the next question).
Partly. An Admin can delete an account's files, events and contacts before restoring them. It is meant for recovering from ransomware or an account someone else has taken over. Only Admins see the option. It is not offered for shared drives, or for a restore of mail alone.
In the restore dialog for a whole account or the workspace (More on the restore bar), tick Delete the files, events and contacts in … now, before restoring and type DELETE. If you chose one kind, such as Drive, only that kind is deleted. The restore then permanently deletes what is there now and puts the chosen backup back. It cannot be undone, so choose the last backup from before the problem started.
Mail is never deleted. That needs full access to each mailbox, which GWS Backup does not ask for. The backed-up mail is added alongside what is there, with the label Restored.
Stop whatever caused the problem first: reset the affected accounts' passwords and sign them out. Do not suspend them, because a suspended account cannot be restored into. If the restore is paused or stopped, resuming it never deletes again.
No. They come back as Word, Excel and PowerPoint files, because that is how they are backed up: Google files have no bytes of their own, so each one is exported to its Office format at backup time. They are not turned back into Google files on restore.
Drive opens and edits the Office files as they are. To get a Google file again, open it and choose File → Save as Google Docs (or Sheets, or Slides): that makes a Google copy beside the Office file.
The restore screens say this too, whenever Drive files are included.
Wherever they came from, as far as the app can tell. Every indexed Drive item records its original folder path, and a restore rebuilds that tree in the target.
The exceptions:
[Restored from …]. Shared drives always go into an account like this, even in a whole-workspace restore.Unfiled, inside that folder if there is one, rather than being scattered at the root of someone's Drive.Items you select and restore from the restore bar follow the same rules, but there is no folder to name. Mail is not put in folders: it gets the label Restored as well as its own.
Yes. For a whole account, choose it on the Restore page, click More → Restore this account… and pick the account under Into. For a few items, tick them and pick the account under Restore into on the restore bar.
Nothing is mixed in with that person's own data. Files go in a folder named after the original account, mail gets the label Restored/ with that name, and events and contacts are marked [Restored from …]. This is how you handle a leaver: their mail and files go to a manager or an archive account, kept apart from that person's own.
Note that restoring into an account counts against that account's 750 GB daily upload cap, not the original owner's.
Yes. A deleted account can always be restored from — its backup is intact and independent of whether the user still exists.
What cannot happen is restoring into it: Google will not issue a token to impersonate an account that is gone. Choose an active account to restore into, and everything goes there marked with the deleted user's name: files in a folder named after them, mail under a Restored/ label. The Restore page says so before you start. A whole-workspace restore names every account that no longer exists, and skips it.
No. Every item written back is recorded against the restore, so a resume skips what is already done and continues from there, from the same backup and into the same place.
One caveat worth knowing: the record is per file, so resuming a partially-processed contacts file can re-create contacts, because the contacts API has no way to say "this one already exists". Calendar events are safe — they are imported with their original identifier, so a repeat updates rather than duplicates.
No. There is no undo button, but what a restore adds is easy to find:
[Restored from …]. To keep a restore into the same account together, name a folder under Into a folder.[Restored from …].Clear up test restores before the next scheduled backup. Restored items are new to Google, so the next backup copies them again, adding to storage and the index.
For a whole account or the whole workspace, the restore dialog gives a rough size before you start: about how much data, across how many items. If more than half of Google's 750 GB per-user daily cap would go into one account, it says so. If it is more than the cap, it says roughly how many days to expect, pausing and resuming as it goes.
Treat it as a guide. It counts every stored version of each file, though a restore writes back only one, so it can be too high. Items backed up before size tracking have no recorded size, which makes it too low, and the dialog says when that applies. Items you select and restore from the restore bar have no estimate: each is restored there and then, and shows its own result.
Retention works on the backup, never on the live Workspace. There are two separate rules, both under Settings → Retention.
Version history decides how many past copies of a changed file are kept: every backup for a period you choose, then one a week, one a month, one a quarter and one a year for as long as you set. The newest backup is always kept. New installs start with it on, at the Standard setting (about five years of history). The page shows, for each client, what the next pass would remove before anything is saved. On an install updated from an earlier version with it already on, nothing is removed until an Admin has seen that figure and confirmed it. One rule covers every client; an Admin can leave a client out in the client's Settings, under Version pruning.
Deleted items are kept for a fixed 365 days. When something disappears from the customer's Workspace, its backup stays restorable for a year and is then removed for good, as long as the Deleted items switch is on (new installs start with it on). Switched off, they are kept for ever. Version history cannot cut the year short.
Only an Admin can change either rule.
No. Retention only ever removes two things, and neither is in Google to be downloaded again.
If a file changes later, or something comes back into the Workspace, the next backup copies it as normal.
For the backup data itself: roughly what the Workspace holds, plus the past versions your version history keeps, plus anything deleted from the Workspace in the last year. Files are stored as they are, not compressed. A file that has not changed is never copied again, but each new version of a changed file is a full copy. Settings → Retention estimates, for each client, the storage its version history will settle at.
The app's own database is small by comparison — typically a few hundred MB even for large estates. Settings → System lists each database file and its size. Housekeeping tidies them every night, and compacts a file when enough space inside it is free.
The console's own nightly backup goes to your destination as well. It keeps one set for each of the last 7 days and each of the last 4 weeks, each set about the size of the databases.
One console database plus one database per client.
gws-backup.db — the console: settings, users, clients, schedules and logs.clients/<clientId>.db — one per client, holding that client's backup index. This is almost all of the data.gws-backup-archive.db — older installations only. One left empty by the old migration is not used and can be deleted.They must always travel together. A copy of gws-backup.db alone is your settings and none of your backups. The installer, the console's own database backup and the restore script all handle the whole set.
An installation that began before v0.96 and was never migrated still keeps everything in gws-backup.db. Version 1.00 will not open it: it changes nothing, does not start, and writes STARTUP-BLOCKED.txt saying what to do (install 0.9613, run its two migration scripts, then install 1.00). Every install made from v0.96 onwards needs nothing.
Only an Admin can change it, under Settings → Destination, and only while no backup is running. The new destination is tested first, with a real write and delete. If the test fails, nothing changes. The change applies to every client at once.
The old destination becomes restore-only: nothing there is deleted, and nothing new is written to it. Each client's next backup is a full one at the new destination, copying everything that is in the Workspace now. After that, backups are incremental as usual.
Nothing is lost from Activity or from any client's History: both live in the console's own database, not at the destination. Activity records the change.
Yes. Restore from still lists the backups made before the change, and restoring from one reads from the old destination. That works for as long as the old storage account stays open and the console can still sign in to it.
Copies at the old destination do not age out: the 365-day clean-up of deleted items only works on the current destination. So the old one keeps its full size, and its cost, until you retire it.
No. The new destination starts with a full backup of what is in the Workspace today. The backups made before the change, with the earlier versions of files they kept, stay at the old destination.
What could be lost is anything that exists only at the old destination: items deleted from the Workspace before the full backup ran, or ones that backup could not copy. Rescue copies the latest copy of each of those to the new destination. It only adds, and running it twice does no harm. It is under Settings → Destination: click Review and retire under the old destination.
Retire it: on Settings → Destination, click Review and retire under the old destination. Only an Admin can.
Afterwards those backups no longer appear under Restore from. They stay in the client's History, marked as removed, and Activity records the retire. There is no undo.
About to lose access to the old storage, for example because the subscription is ending? Retire it before you do: once the console cannot reach it, it cannot delete what is there either.
Use Forget this destination, at the bottom of the same panel. It removes the console's records of everything held there, for every client, and deletes nothing at the storage. Whatever is still there stays, and stays on that storage's bill, until whoever controls the storage deletes it. The console cannot delete it later.
The dialog first checks whether the console can still read from it; if it can, retire it instead. To forget, you tick each loss: that nothing there is deleted, that the backups made before the change can no longer be restored, and that anything held only there is given up. Then you type forget. Only an Admin can.
Forgotten backups leave Restore from and stay in each client's History, marked as forgotten. A destination with nothing held there can be forgotten too, which simply takes it off the list.
It is the master key to your backups, not a server setting. One key per installation encrypts:
What it protects is the copies in your storage: leaked S3 keys, a Drive folder shared by mistake, a lost disk. The key sits on the server beside the database, so it does nothing against someone who has the server itself.
If you lose it, that data cannot be recovered by any means. Not by us, not by anyone. It is 32 random bytes and there is no back door.
Keep it in a password manager and somewhere offline, off the server it belongs to, and never stored alongside the backups themselves. An Admin can download it from Settings → Users & security, under Encryption key, after typing their password again; the download is recorded in Activity.
With the key you can read your backups without the app. decrypt-backup.mjs comes with every download: node decrypt-backup.mjs --in <folder> --out <folder> --key-file <your key file> turns downloaded backups back into ordinary files and emails. Without the key nothing encrypted can be read, by anyone.
There is no rotation: nothing re-encrypts existing data, so changing the key orphans everything already stored.
The encryption key, first and above everything else. Put it into the new server's .env before the first boot, and certainly before restoring a database.
A fresh install generates its own key. Restore a database on top of that and the console will come up looking perfectly healthy — every client, every setting, every schedule — while nothing encrypted can be read and nothing explains why. The restore checker (restore-console-db.mjs) tests exactly this before it will install anything.
Only the key has to travel. The session secret can be regenerated (it only signs everyone out), and the database path, public URL, port and edition describe one specific server — check them rather than copying them.
An Admin gives each person their role under Users on Settings → Users & security. A changed role applies on that person's very next click, not when their session runs out. Setting someone a new password signs them out everywhere and unlocks their account.
Controls only an Admin may use are shown only to Admins. On Activity, Operators and Viewers see backups and restores, not sign-ins or settings changes.
Each person turns it on for themselves on Settings → Users & security, under Two-step sign-in (2FA) — scan the QR code with any authenticator app, confirm one code, and it is on. It applies per account, not per installation.
If someone loses their authenticator, an Admin can turn it off for them from the Users list on the same page: the account then signs in with its password alone until they set it up again. That reset ends their existing sessions and is recorded in Activity.
If no other Admin can do that, the Admin made at setup can use the recovery key: it turns off two-step sign-in as well as resetting the password. A wrong code counts as a wrong try, the same as a wrong password: see the next question.
Wrong tries are counted for each account, like a phone's lock screen. Wrong two-step codes count too.
While you are waiting, even the right password is refused, and those tries do not count. Signing in successfully starts the count again.
To unlock an account:
A lock does not sign out anyone already signed in to that account, so someone guessing cannot throw the real person out. Locks and unlocks are recorded on the Activity page, under Sign-ins.
Too many tries from here is a different message: many sign-ins came from one address in a short time. Wait ten minutes, then try again.
The console never sends email, so there is no "reset my password" link. The recovery key is the substitute: a one-off secret made with the first account during setup. Use it from Forgotten your password? on the sign-in page.
It always resets the Admin account made at setup, even if that account's email address has changed since, and never anyone else's. In one step it sets a new password, turns off two-step sign-in, unlocks the account if too many wrong tries locked it, and makes it an Admin again. Anyone still signed in to that account is signed out. The page then names the account to sign in as, and the reset is recorded on the Activity page. Any other account's password is set by an Admin, under Users on Settings → Users & security.
Because it does all that, the key is enough on its own to get into the account. Keep it offline and treat it like the encryption key. It is shown once. An Admin can make a new one on Settings → Users & security, under Password recovery key, which also names the account it resets; the old key then stops working. An install with no recovery key set has no password recovery path at all, and the page says so.
A second Admin is the other answer, and needs no secret to look after.
The recovery key only ever resets one account: the Admin made when the console was set up. That stays true if the account's email address has changed since, and if the account was deleted, using the key makes it again. After the reset, the page names the account: sign in as that one, with the new password. Tell its owner, and if they used two-step sign-in they need to set it up again.
If you were trying to get into your own account and it is not that one, ask an Admin to set you a new password, under Users on Settings → Users & security. That also unlocks your account if it was locked.
An Admin can see which account the key resets on the same page, under Password recovery key.
Nobody can read it in the console. GWS Backup does not open backed-up email or files for reading: it backs them up and puts them back. To help you find a message, the Restore page lists its sender, subject and date, and only Operators and Admins see that list. Restores, and who started them, are recorded on the Activity page.
Install it on your own servers (one running installation per key, which you can move whenever you like), protect as many Google Workspaces as your key allows — ten on the free licence, more by arrangement — and use it commercially, including providing backup services to your own paying clients.
What you may not do is rebrand or re-market it as your own product, resell or redistribute it or its licence keys, remove the GWS Backup or KIKO Solutions branding, or reverse-engineer it. If you want the console to carry your branding alone, that is what the white-label programme is for — get in touch.
Each key permits one running installation at a time. You may move an installation to a different server whenever you like, but the same key must not be live in two places at once — including a staging copy that happens to be running.
Key usage is monitored. If you need failover, clustering or a lab environment, ask rather than running two: it is usually easy to arrange.
Nothing stops. The licence is checked in the background, when someone signs in and about every six hours, and pages never wait for it. If the check cannot get through, the console keeps working on the answer it already holds and shows a banner saying the licence was not re-checked, with Try again.
Licensing will never stand between you and your backups: it only blocks when there is an actual verdict — no key entered, or a key that has genuinely been rejected. A network problem, a missing setting or an error on our side is treated as "unknown" and gets out of the way.
The app found a database with real data in it, but no ENCRYPTION_KEY in the environment. It stops rather than generating a new key, which would make your existing backups unreadable.
Fix it in this order:
.env file from your safe copy. It must carry the original key.ENCRYPTION_KEY in the hosting panel's environment.The same message is written to STARTUP-BLOCKED.txt in the app folder, for hosts where the console output is hard to reach.
The client's domain-wide delegation does not cover a scope the app is asking for — one missing scope fails the whole connection.
Go to the client's Google Admin console → Security → API controls → Domain-wide delegation, find the service account's Client ID, and make sure the scope list matches exactly what the client's Connect page shows (it has a button to copy them).
Restores need more scopes than backups — backups are read-only — so a client whose backups work can still fail to restore if the list was cut short. Test on the Connect page checks what backups need. The restore dialog (More on the restore bar) checks the restore scopes before a whole-account or whole-workspace restore, and names any that are missing.
Your browser could not get an answer from the console. Nothing you saved earlier is lost.
Something went wrong on this page is different: the page itself hit a problem. Click Try again. If it keeps happening, send us the Reference it shows, with the log from Settings → System.
Not found means there is nothing at that address, usually an old link to a client that has since been deleted.
Almost certainly the wrong encryption key. If a database is restored onto a server holding a different ENCRYPTION_KEY, the console starts, you can sign in, and every client, setting and schedule is present — but nothing encrypted can be decrypted, so every connection fails.
Check the key fingerprint shown on Settings → Users & security, under Encryption key, against the one recorded in the backup you restored. When the key does not match the data, that page says so in red, and the app logs a loud warning at startup.
The answer is always to restore the original key, never to re-enter the credentials — the stored data is still encrypted with the old key.
The storage is slowing down deletes on that account. Google Drive does this after a very large delete, such as another client's. The console has already waited and tried again for nearly a minute before saying so.
When the storage says how long to wait, the message gives that time. Google Drive does not say, so try again in a few minutes. What was already deleted is skipped, and nothing else is removed until every storage location has gone, so no backup is left with nothing pointing at it.
The Activity page, in the sidebar. Every backup run, restore, sign-in and settings change is one plain sentence, with who did it and when. Admins see everything; Operators and Viewers see backups and restores. A client that has since been deleted keeps its name there, marked (deleted).
It can be filtered by kind (Backups, Restores, Sign-ins, Settings, System), searched, and narrowed to a date range. Wrong passwords, locked and unlocked accounts and recovery-key resets are under Sign-ins.
For one client's runs, its History page lists every run with what it did and any errors, can show problems only, and downloads as a CSV.
No — support is free for everyone, including the free ten-workspace licence. If that ever changes, we’ll say so plainly and well in advance.
Email support@gwsbackup.com with:
Please do not send your .env file, your encryption key or a database copy unless we specifically ask. If we do, we will tell you how to send it safely.
No answers match your search.
Try a different word, or send us your question — good ones end up on this page.