1. CubeBackup Documents
  2. FAQ
  3. Does CubeBackup support Object Lock and immutable storage?

Does CubeBackup support Object Lock and immutable storage?

Many cloud storage providers offer additional data protection features, such as Object Lock, Immutable Storage, Object Versioning, Soft Delete, and Retention Policies, to prevent backup data from being accidentally or maliciously deleted.

As a self-hosted backup solution, CubeBackup not only protects your Google Workspace and Microsoft 365 data with unlimited revision histories, but also is compatible with these storage-level protection mechanisms to provide an additional layer of security for backup data.

This article explains how CubeBackup works with these features, their compatibility, and the potential impact on storage usage and operating costs.

Data protection in CubeBackup

CubeBackup already provides built-in protection against accidental data loss through its snapshot and retention mechanisms.

Each backup creates a new snapshot while preserving previous recovery points according to the configured retention policy. Even if users delete emails, files, calendars, contacts, or other protected data from the production environment, those items remain recoverable from existing backup snapshots until they expire based on the configured retention policy.

In addition, when a user is removed from the source tenant, CubeBackup preserves that user's existing backups at no additional license cost. These backups remain available for restore even after the user account has been deleted.

More information can be found here:

However, these protections assume that the backup repository itself remains intact. If an attacker or unauthorized administrator gains access to the backup storage and permanently deletes the backup data, CubeBackup cannot recover backups that no longer exist in the storage repository.

Storage-level protection mechanisms such as Object Lock or immutable storage are designed to address this scenario by preventing backup objects from being deleted or modified, even if the storage credentials are compromised. CubeBackup can work with these storage-level protections, but the final immutability guarantees are provided by the storage platform itself.

Compatibility with immutable storage features

CubeBackup is fully compatible with most storage-level immutability features. You can enable them without affecting normal backup and restore operations, provided that the storage service continues to allow CubeBackup to:

  • overwrite existing backup objects when necessary; and
  • submit object deletion requests (even if the storage system delays or protects the actual deletion).

Note: For Google Cloud Storage users, while Object Versioning and Soft Delete are fully supported, Bucket/Object Retention Policies/Lock is not supported. This is because these policies reject overwrite and deletion requests until the configured retention period expires, which prevents required maintenance operations in CubeBackup.

Storage usage considerations

The built-in version control mechanisms of CubeBackup periodically update internal index files during backup operations and delete obsolete files that no longer exist in any snapshots.

When Object Lock or other immutable storage features are enabled, previous versions of overwritten objects may be retained for an additional period, and obsolete files that are no longer needed will not be removed immediately.

As a result, multiple versions of the same object and deleted objects may remain in storage. Storage consumption may increase over time, leading to additional storage costs.

In addition to versioning overhead, some cloud storage providers impose a minimum storage duration policy for stored objects. For example, providers such as Wasabi may charge for the full minimum retention period even if an object is overwritten or deleted earlier. Since CubeBackup continuously updates certain metadata files, these storage policies can result in additional storage charges beyond the actual amount of data retained.

Estimated cost of data index synchronization

CubeBackup periodically updates its index files to keep the backup repository synchronized. Most of these files are SQLite database files (*.sqlite) that store backup metadata and snapshots, and are synchronized to the backup storage on an hourly or daily basis.

Based on typical deployments, retained versions of CubeBackup's metadata files can generate approximately 50–200 MB of additional storage per protected user per day, depending on the backup workload and data change frequency.

For this reason, we recommend considering both when generating your total solution cost estimate:

  • the additional storage consumed by retained object versions when enabling storage-level immutability features; and
  • any minimum storage period or early-deletion charges imposed by your storage provider.