Do you remember when you were a kid playing board games and you made a bad move? You could do a take back or a do-over and go on with your game without penalty. Life usually doesn’t work that way, but with the new object versioning feature of Swarm 8.0, you can take back a mistaken update or undo a delete very easily. No harm, no foul.
We built the object versioning feature to be compatible with S3 versioning, available to all customers who upgrade to Swarm 8.0. S3 versioning is an industry-standard capability, but Swarm’s object versioning extends that capability with our HTTP interface. The feature allows past versions of tenanted alias objects and named objects to accumulate, be listed via Swarm Search, and be accessible by their version ID (ETag). To revert to an earlier version, use the COPY operation to make older versions current again. Deletes of versioned content are done using delete markers, so erasing the delete marker is all that’s necessary to restore the previous version. Individual versions can be directly erased, too, including the current one. That is the easiest way of unwinding the latest update and restoring the previous version of a particular object.
Every benefit has a cost. Each version will consume disk and index space within a cluster. For erasure-coded objects, APPEND and COPY operations create versions that share the same underlying data, so multiple APPENDed object versions, for example, will not duplicate the original data. Of course, the erasure-coded data will remain intact as long as there’s a version that references it. In order to make it easy for customers to control versioning within their cluster, we have provided a new policy mechanism that allows cluster, domain, and bucket administrators to individually specify policies at those levels for how versioning should be applied. The cluster administrator can disable versioning (the default) or allow the domain administrator’s choices to be in force. Similarly, the domain administrator can allow versioning on specific buckets based on policies on those bucket objects.
Using policies, customers can suspend versioning, which retains old versions but prevents new ones from accumulating. Disabling versioning will make old versions inaccessible and clean up their space utilization. Policy decisions can be made differently in different clusters so remote replication can save or retain older versions, as needed. Versioning works with the Swarm Lifepoints feature, so it is easy to set an expiration time on a versioned object which will allow older versions to be automatically removed and their space reclaimed.
Object versioning readily supports multiple backups for customers who use Swarm for archiving. However, we know that some of our customers are implementing their own versioning mechanisms as an application layer on top of Swarm. Consider allowing Swarm to do the work of keeping older versions for ready access. We’d like to hear from you! Be one of the first 5 customers to share your experience with the new versioning feature in Swarm and you’ll be entered to win a deluxe Caringo beer drinking set! Send your story to email@example.com.
Want to learn more about object storage? Check out our upcoming webinars:
The performance figures achieved are results of Caringo Swarm’s underlying parallel architecture. Let's describe the infrastructure, methodologies and results achieved. More Details »
What are the characteristics of each storage tier and when should you use NVMe, SAN, NAS, Cloud, Object, or Tape Storage? More Details »