Remote Storage
Remote Storage sends your backups off the server, where they survive a disk failure or a lost machine, the way JetBackup's destinations do. Connect a cloud bucket or an SFTP host once, test it, and finished backups sync there automatically, tracked job by job.
Backup → Remote Storagehttps://YOUR-SERVER-IP:8443/backup/remoteThree tabs
The page has three tabs. Destinations holds your storage targets as cards, each showing provider, region, connection status, sync counts and its four actions. Sync Jobs is the live queue: every upload with its status, a progress bar while uploading, and retry or cancel. Remote Backups lists what actually sits at each destination, with a per-item flag for whether a local copy still exists, plus download and delete, which is your disaster-recovery entry point.
Four cards across the top track connected destinations, total syncs, total bytes uploaded and pending jobs.
Supported destinations
Five providers, each set up through a three-step wizard (basic info, provider config, test and confirm).
| Provider | Key fields you enter |
|---|---|
| Amazon S3 | Access key, secret, region (16 AWS regions), bucket, storage class, optional server-side encryption |
| S3-compatible | The above plus a custom endpoint and path-style toggle (Wasabi, DigitalOcean Spaces, MinIO) |
| Google Cloud Storage | HMAC access key and secret, project ID, bucket, location (26 options), storage class |
| Google Drive | OAuth: client ID and secret, then authorize in a Google popup |
| SFTP | Host, port, username, password or SSH private key, then browse to a folder |
Amazon S3 and S3-compatible, field by field
Enter your access key and secret, pick a region and name a bucket. Under Advanced Options you choose a storage class and optional server-side encryption (none, SSE-S3 AES-256, or SSE-KMS with a key ARN). The storage class is a real cost decision, so the panel labels each:
| Storage class | Use it for |
|---|---|
| STANDARD | Frequent access, highest cost, instant retrieval |
| STANDARD_IA / ONEZONE_IA | Infrequent access, lower cost, retrieval fee |
| INTELLIGENT_TIERING | Mixed or unknown access patterns |
| GLACIER_IR | Archive with instant retrieval |
| GLACIER | Archive, minutes-to-hours retrieval, very low cost |
| DEEP_ARCHIVE | Cold archive, cheapest, hours to restore |
For S3-compatible storage you additionally give the provider's endpoint URL and usually enable path-style addressing. Bucket paths are auto-managed as bucket/year/month/filename, so there is no prefix to configure, and the panel can create the bucket for you (off by default, so a typo never spawns an orphan bucket).
Google Drive: the OAuth flow
Google Drive is the one that trips people up, so it is a guided three-step form. First you create OAuth credentials in Google Cloud Console (the form links straight to enabling the Drive API and creating the credential, and gives you the exact redirect URI to paste, copyable with one click) and enter the client ID and secret. Second, you click Authorize with Google, which opens a Google consent popup and, on success, stores the resulting refresh token; the card turns green and gains a Reauthorize button for later. Third, you pick the backup folder: Create Folder (Auto) makes a "Panelica Backups" folder for you, or Enter Manually takes a folder ID. A built-in setup guide walks through the consent-screen and test-user steps.
SFTP: connect and browse
Enter host, port and username, choose password or SSH private key authentication (the key goes in as PEM text with an optional passphrase), then click Connect & Browse. The panel opens a live directory browser on the server: navigate folders, create a new one, and select the target path (the root / is refused, you must choose a real folder). Backups then land under your-path/year/month/.
Every button
| Button | Where | What it does |
|---|---|---|
| Add Destination | Top bar / empty state | Opens the three-step wizard |
| Test (in wizard) | Wizard step 3 | Tests the connection before saving, reporting list/read/write/delete permissions and latency |
| Test (on a card) | Destination card | Re-tests a saved destination; also counts the backups already there (disaster-recovery discovery) |
| Set Default (★) | Destination card | Makes this the default target; a disabled destination cannot be default |
| Edit | Destination card | Re-opens the config; credential fields start empty and are only changed if you retype them |
| Delete | Destination card | Removes the destination, with a second prompt to keep or delete the S3 bucket, and a force option if the remote is offline |
| Retry | Sync Jobs (failed job) | Re-queues a failed upload from scratch |
| Cancel | Sync Jobs (queued job) | Cancels a job that has not started uploading |
| Download | Remote Backups (remote-only) | Pulls a backup from the cloud back to local disk |
| Delete (remote backup) | Remote Backups | Removes a backup from the destination (ROOT only) |
The sync queue, and why it heals itself
Uploads run through a small worker pool as jobs that move through queued, uploading and succeeded (or failed, partial, cancelled). The queue is built to be trusted unattended:
- De-duplication: the same backup is never uploaded twice. Before queuing, the panel checks for an active job and, if a past job reported success, actually verifies the file still exists on the remote; if it was deleted there, it re-queues rather than falsely skipping.
- No two workers, one job: jobs are claimed with a locked database transaction, so parallel workers never collide.
- Backoff on failure: a failed job retries with growing delay up to three attempts, and the backoff is preserved even across a re-queue.
- Atomic downloads: a pull from the cloud writes to a
.partfile and renames on success, so a half-finished download never masquerades as a real backup or blocks a retry; S3 downloads are checksum-verified. - Tenant isolation: a customer's backup only ever syncs to that customer's (or the system-wide) destinations, never a neighbor's bucket.
- Self-cleaning: an upload stuck for over an hour is failed, and orphaned job records for backups that no longer exist can be pruned.
The Sync Jobs tab refreshes every ten seconds, so you see progress without reloading.
Disaster recovery
This is what remote storage is for. Testing a destination discovers the backups already there, so a fresh, empty panel with nothing but your cloud credentials immediately sees its history. The Remote Backups tab lists them and pulls any one back with Download.
Security
Credentials are encrypted at rest and never returned to the browser, which is why edit forms never pre-fill a password or token. Error messages are scrubbed of access keys, secrets and KMS ARNs before you ever see them, and a wrong-region or wrong-credential mistake is turned into a plain-language explanation rather than a raw AWS error. Backup filenames are validated against path traversal, and the whole feature is license-enforced server-side on every single sync (a lapsed license refuses the upload with a clear upgrade prompt, even for a job already in the queue).
Access
Behind the backup_remote license feature. Destinations are scoped by the roles and permissions chain (ROOT sees all, admins and resellers see system-wide plus their own, users see their own), and the per-action permissions (view, create, edit, delete, test, set-default, download) default to ROOT and ADMIN, with deleting a remote backup and pruning orphan jobs reserved for ROOT. ROOT also gets a Global Settings shortcut to the panel-wide backup configuration.