Backup storage

Use Object Storage Repositories whenever possible for better scalability, security and client segregation - either on-premises or in the cloud.
Use JetDB-backed repositories on block storage when Object Storage is not available. Avoid using JetDB-backed repositories on SMB storage as support is experimental. Use SMB only for testing, not in production.

Depending on the client’s requirements and service offering (shared multi-tenant platform or dedicated platform per client), there are some things we need to take into account:

• Storage consumption
  • Backup data stored in JetDB-backed repositories are not compressed nor deduplicated. This significantly increases storage consumption.
  • Backup data stored in Object storage is compressed before storing. This significantly reduced storage consumptions by ~50%.
• Data locality
  • The client or law requires that data must not leave the country.
  • This scenario supports JetDB-backed repositories and on-premises object storages.
• Data portability (e.g. exit strategy)
  • When offering the client the option to leave the service, a JetDB-backed repository makes it very easy to make a copy onto a portable media and hand it over to the client. The JetDB repository consists only out of a folder with several (.adb) files that hold all the backup data.
  • With on-premises S3-compatible object storage, you can use native S3 copy tools to copy the backup data to another S3-compatible object storage.
  • With Azure Blob or AWS S3 object storage, you can also use native copy tools to copy backup data to another storage container/bucket. If only the latest restore point is required or sufficient, you can leverage the Backup Copy job to an Azure Blob Storage Archive, Amazon S3 Glacier or Amazon S3 Glacier Deep Archive storage that could be owned by the client or another 3rd party.
  • In case it is not possible to migrate old data, the new backup service provider will have to start the backup all over again. You can discuss with the client on how long the existing backups need to stay available on your platform depending on their legal obligations or other requirements.
• Client segmentation
  • For security, data portability and flexibility reasons - the best practice is to create dedicated backup repositories for each client.
  • With JetDB-backed repositories, backup data is stored in .adb files on the file system. When segmenting clients, each client gets its own set of .adb files and client backup data does not get mixed with other clients.
  • With Object storage, creating separate S3 buckets or Azure blobs allows for better security due to the use of separate IAM policies and own credentials.
  • Segmenting client repositories allows for easier billing. JetDB-backed repositories’ total can be checked by adding the size of each backup folder on the file system or if dedicated volumes are used, just check the used/free space on the client’s volume. Object storage repositories already show the used storage in the UI or via PS/API.
• Encryption
  • Only object storage supports encryption and compression, thus being more secure and space effient than local JetDB-backed repositories.
• Scalability
  • Object storage scales infinitely as storage nodes can be added easily in the back-end.
  • Object storage only uses JetDB-backed repositories as cache, thus decreases memory consumption and avoids performance issues.
• High availability
  • Object storages provides high availability by default thanks to the clustered back-end. When a storage node goes offline or even an entire data center goes offline, the backup data still remains available and accessible.
• Secondary copy (comply with 3-2-1)
  • Only supported for Backup Jobs that use AWS S3- and Azure Blob backed object storages.
  • Backup Copy jobs can only target Azure Blob Storage Archive, Amazon S3 Glacier or Amazon S3 Glacier Deep Archive storage.

---