Last modified June 29, 2026

JetBackup Storage

Learn how to configure and manage JetBackup Storage backup destinations.

For video tutorials, please click here:


Creating the Destination

This guide shows how to add a JetBackup Storage backup destination to JetBackup.

JetBackup Storage has two distinct account types, each using a different destination setup:

Integrated Storage accounts are simplified, bucket-only accounts created directly through JetBackup using the “Quick Access” signup. They do not expose a standard S3 console for managing buckets/bucket settings, keys, etc. — instead, access is granted via a Quick Access Code generated through the JetBackup Client Area. Use this destination type if you created your storage account through the Get Quick Access Code button on this page. You do not need to create an Access/Secret Key pair; the Quick Access Code handles authentication automatically.

S3 Storage accounts are full JetBackup Storage accounts with standard S3-compatible API and console access, giving you full control over bucket creation, users, regions, and Access/Secret Key management. Because these accounts expose standard S3 credentials and all S3 features, they must be configured using the S3-Compatible Destination instead of this page. Use the guide Integration with JetBackup 5 to create your Access/Secret Key pair and associated bucket. Do not use the Quick Access Code button when using Self-Managed JB Storage accounts — it will create a separate Integrated S3 account instead.

NOTE: Kindly ensure Bucket settings such as Bucket Versioning, Object Lock/Governance Mode, Object Lifecycle are disabled as these settings are UNSUPPORTED and can be expected to cause issues with your backups.

An example JetBackup Storage configuration page for the destination:

Destination Name

Specify a unique name for your destination. This will be used internally for your convenience.

Read Only

This option allows you to add the destination as a “Read Only” destination. You can only restore and download existing backups from a read-only destination. Read Only is required if the Backup Directory is already owned by another destination/server. This option is only selectable upon creating the destination and will be automatically enabled for any destinations added during a Disaster Recovery.

Owner

Specify the owner for this destination. This grants the owner and its parent account(s) permission to modify and delete this destination. Please note that the owner specified will also need Can Manage Destinations permission granted under the Permissions section.

Maximum Concurrent Threads

This option allows you to set the number of worker threads that can be used by the destination for upload/download/get/delete requests. This will be shared evenly across the number of Concurrent Tasks set for Backup or Restore/Download. As the tasks complete, the available threads will be allocated to the remaining active tasks up to the set limit. You can lower this value if you receive rate-limit errors from the remote destination.

Get Quick Access Code

Use the “Get Quick Access Code” button on the page to use an Integrated JetBackup Storage account. A popup will be displayed prompting you to enter your JetBackup Client Area (billing.jetbackup.com) login credentials or creating a new account. The Access Code will be displayed upon selecting the Region, or a pre-existing bucket. Copy and paste the code in this box to quickly create and authenticate to the destination.

During first-time signup, choose a Region that’s geographically close to your server for the best backup performance as the region cannot be changed on Integrated JB Storage Accounts.

Advanced Options for JetBackup Storage Destinations

Expand these options by clicking “Show advanced settings.”

Backup Directory

This will be our starting point when accessing this destination. Always use the absolute path and make sure to start with “/”.

For example: /PATH/TO/FOLDER.

Note: The absolute path must be unique and can not be used by two different Destination Configurations. If a backup directory is already owned by another JetBackup Destination, you may create a “Read Only” Destination to that path.

Only the following characters are allowed for the Backup Directory Path: A-Z a-z 0-9 and /.

Verify SSL

Whether SSL verification is enabled/disabled on the JetBackup Storage destination. [ default: Yes ]

HTTP Retries

Controls how many retries will be attempted if the destination returns an error for an HTTP call (upload / download / delete). [default: 3 retries]

Large files upload chunk size

Select the multipart upload chunk size for large files. Lower this value if you find large files are failing to upload. [default: 5120 MB]

Keep Alive timeout

The time in seconds, that the host will allow an idle connection to remain open before it is closed. [default: 60 seconds]

Max Keep Alive Requests

The maximum number of requests that can be sent on a single connection before closing it. Choose “Determined by remote vendor” to fetch the maximum keep alive requests automatically. [default: 100]

Low Speed Timeout

Require at least 1 byte in the configured interval otherwise the connection is considered slow and connection is aborted. Increase this for slow or unstable connections. [default: 120 seconds]

Upload Verification

Ensures the uploaded file is successfully stored on the remote destination by reconnecting and verifying its presence using getObject.

WARNING: Enabling this feature may result in significant performance downgrade due to additional verification steps on each uploaded file.

Additional information

Object storage is a type of storage where data is stored as objects rather than blocks. This concept is useful for data backup, archiving, and scalability for high-load environments.

Objects are the entities of data storage in JetBackup Storage buckets. JetBackup Storage objects are comprised of three main parts; the content of the object (data contained in the object including directories or files), the unique object identifier (Unique string used to identify the item within the bucket.), and metadata. Metadata contains information such as name, size, date, security attributes, content type, and URL. Each object has an ACL or Access Control list which dictates who is permitted access to the object. JetBackup Storage has distinct advantages such as allowing you to avoid network bottlenecks as well as a high degree of scalability and data security.

JetBackup Storage vs Traditional File System Comparison

JetBackup Storage uses object storage where data is stored as objects with unique identifiers, compared to standard file storage where your data are stored in files and directories and are human-readable.

As an example, this is how a snap is structured on JetBackup 5’s backup format, organized per backup item plus additional metadata for JetBackup’s use:

.
├── snap.1
│   ├── certificate
│   ├── config
│   ├── cronjob
│   ├── database
│   ├── database_user
│   ├── domain
│   ├── email
│   ├── ftp
│   ├── homedir
│   ├── jetbackup.configs
│   └── jetbackup.index
├── snap.2
 ....

Once this data is transferred to a JetBackup Storage Destination, this is then converted and stored as objects and will look something similar to the following:

.
├── export
│   ├── snap.1
│   ├── snap.2
│    ....
├── files
│   ├── 6258c0a30008839f00001146
│   ├── 6258c0a30009115600001148
│   ├── 6258c0a3000914d000001149
│   ├── 6258c0a30009180b0000114b
│   ├── 6258c0a300091a820000114c
│   ├── 6258c0a300091f3400001151
│    ....
├── snap.1
│   └── jetbackup.index
├── snap.2
│   └── jetbackup.index
....

Under “files”, this is where backup data across all the snaps are actually stored, and each object represents a file in the backup. Additionally, there will also be a corresponding “snap” and “export” data which stores the information required for JetBackup to read this backup.

JetBackup Storage Object Integrity

Please be aware that when utilizing JetBackup Storage destinations, a file hashing mechanism is employed to ensure object integrity during the file upload process. This procedure involves generating a hash of the file, transmitting it to the JetBackup Storage server, uploading the file, and subsequently hashing the file again on the JetBackup Storage server using the same algorithm. JetBackup Storage then compares these two hashes, and if they do not match, the file upload is declined. As this is required for all file uploading to JetBackup Storage, this cannot be disabled at the JetBackup level. With this in mind, we recommend excluding certain files that are regularly written to (logs, temp files, etc.) to mitigate partial backups.

JetBackup Storage Documentation

Additional reading on JetBackup Storage can be found in our JetBackup Storage Documentation.