Managing reversioned files

Having multiple versions of a file on the cloud can be an issue especially when your storage is constrained by space and for maintenance purposes.

cloud services manage reversioned files just as how it manages the deleted files. The cloud destroy utility automatically deletes older versions depending on the retention time associated with each version.

For example, on day #1, you create a file and migrate it to the cloud. This is version 1. The retention time is NOT associated with this file yet as there are no other versions of this file. On day #2, you recall the file, modify it, and migrate it back to the cloud. This is version 2. As soon as this version is created, the retention period is applicable to the previous version (version 1). On day #6, you again recall the file, modify it, and migrate it back to the cloud. This is version 3. Once this version is created, retention period is applicable to the previous version (version 2). Now, you have a total of 3 versions of the file on your cloud storage.

The following sequence of events occurs, assuming the retention period to be 30 days:
  • On day #30, a total of 3 versions of the file are there on the cloud
  • On day #31, a total of 3 versions of the file are there on the cloud
  • On day #32, a total of 3 versions of the file are there on the cloud
  • On day #33, version 1 is deleted as it exhausts the retention time.
  • On day #34, version 2 and 3 are there on the cloud
  • On day #35, version 2 and 3 are there on the cloud
  • On day #36, version 2 and 3 are there on the cloud
  • On day #37, version 2 is deleted as it exhausts the retention time.
  • On day #38, version 3 is there on the cloud
Note: There is not a separate retention policy for managing the reversioned files versus deleted files. The number of days retained is the same for both as they both rely on the same policy value.