Object Versioning

Object-level versioning is a powerful content protection option that tracks, secures, and provides access to historical versions of objects, even after they are deleted. With versioning, applications can read, list, revert, and purge prior versions as well as restore objects deleted by mistake.

Note

Using Swarm versioning with SCSP operations has no dependencies. To use Swarm versioning with Amazon S3, Content Gateway version 4.1 or higher must be run.

Versioning preserves a set of historical variants of an object, the original plus subsequent updates to it, up to and including the latest version:

These are key capabilities of Swarm versioning:

S3 Versioning

Swarm's native object versioning feature is interoperable with AWS S3 versioning. The implementation includes these improvements:

  • Ability to Disable Versioning: 
    AWS S3 allows for versioning to be suspended once enabled on a bucket. Swarm provides the ability to disable versioning and automatically clean up the prior versions to reclaim storage space.

  • Delete Marker Consolidation: 
    Unlike AWS S3 where continued DELETE operations on a deleted object record additional delete markers in the version history, Swarm acknowledges the subsequent deletes without recording additional delete markers. Multi-factor authentication delete is not supported.

  • Expanded Version Listing:
    Swarm supports version listing batches up to 2000 items while AWS S3 limits these listing results to batches of 1000. Additionally, Swarm does not break batches on version boundaries. Delimiter case is currently not supported for version listing.

  • Simplified ACL Management:
    When using per-object ACLs with versioning, the ACL for the current version of the object applies for determining authorization. To change the ACL for an object's entire version chain, update the object without specifying a version.

Why use Versioning?

Versioning meets two key needs:

  • Require extremely durable data retention and archiving.

  • Require the ability to recover when data is erroneously overwritten or deleted.

With versioning enabled, prior versions of a stored object, can be retrieved and restored allowing recovery from data loss, whether caused by user error or application failure:

  • Deleting an Object: Swarm inserts a delete marker instead of removing it permanently, which becomes the current object version. Previous versions can be restored.

  • Overwriting an Object: Swarm performs the update by creating a new version, allowing restoring previous versions by rolling back a bad update.

By default, versioning is disabled across the cluster. To avoid excessive storage usage, enable versioning in a targeted way, where change control is required.

What is Versioned?

Choosing to use versioning enables the ability to preserve, retrieve, and restore every update of every object stored in that context (domain or bucket). With Versioning, Swarm archives another copy of an existing object when an update or delete is processed. GET requests retrieve the most recently written version, but retrieval of older versions of an object is performed by specifying a version in the request.

Administrators can selectively enable versioning at the following levels once the cluster is configured to allow versioning:

  • The domain level (for alias objects)

  • The bucket level (for named objects)

When a DELETE operation is issued against a versioned object, Swarm creates a delete marker so subsequent unversioned requests no longer retrieve the object. Swarm stores all versions of an object so they can be retrieved and restored.

These types of Swarm objects cannot be versioned:

  • Domains

  • Buckets

  • Unnamed objects (which are immutable)

  • Alias objects not tenanted in a domain

Objects are versioned while domains and buckets are not (contexts). A bucket is lost if accidentally deleted. Swarm pauses the recursive delete of the bucket's contents for the duration of the grace period (health.recursiveDeleteDelay). There is time to recreate the bucket with the same headers to avoid data loss (See Restoring Domains and Buckets). The content starts to disappear as Swarm's Health Processor begins cleaning up all versions of the obsolete content, to reclaim space, if the bucket is not restored and the grace period expires.

© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.