JENNY BROWN: Let's face it.
We've all got control issues.
They might keep us up at night, and sometimes
they even limit our ability to work with others.
Fortunately, Cloud Storage Bytes is here to help.
Well, as long as your particular control issues
revolve around dealing with and managing
versioning in the Cloud.
[MUSIC PLAYING]
Have you ever accidentally deleted a file
that you meant to keep?
What about if someone else deletes your stuff?
It's frustrating, to say the least.
More importantly, imagine this experience for your users.
Fortunately, you can course correct and monitor
potential accidental data removal from your Cloud Storage
bucket thanks to object versioning.
For a quick review, Google Cloud Storage
uses object versioning to protect your Cloud Storage
data from being overwritten or accidentally deleted.
Sounds great, right?
So let's get right into how this versioning thing works.
Object versioning gets enabled on a bucket
using gsutil or the REST API.
Once enabled, Cloud Storage creates an archived version
of an object each time the live version of the object
is overwritten or deleted.
That being said, if you move a file,
it effectively loses its history.
So for example, if I have file cat with three versions
and I move cat to chonker, then cat is still there
with three versions, and now chonker
is there with one version.
But as far as Cloud Storage can tell,
there is no connection showing that chonker was once cat.
As for overwritten or deleted objects,
the archived version keeps the name of the object,
but is uniquely identified by a generation number.
All objects have generation numbers associated with them,
but only archived objects require generation numbers
to identify them.
Whenever object versioning is enabled,
you can list archived versions of an object,
restore the live version of an object to an older state,
or permanently delete an archived version
as needed using gsutil or the REST API.
You can turn versioning on or off for a bucket at any time.
Turning off versioning leaves existing object
versions in place, but going forward,
the bucket stops accumulating new archived object versions.
Cloud Storage uses two different properties
that, together, identify the version of an object.
One property identifies the version of the object's data.
The other property identifies the version
of the object's metadata.
These properties are always present with every version
of the object, even if object versioning is not enabled.
They can be used as preconditions
for conditional updates to enforce
the ordering of those updates.
Archived objects have their own metadata,
which may differ from the metadata of live objects.
Most importantly here is an archived version
retains its access control lists,
so it may not necessarily have the same permissions
as the live version of that same object.
Each object, whether live or versioned,
has one set of metadata.
Only the latest metageneration numbers refer to that metadata.
Older metageneration numbers cannot be used to access
metadata that has since been changed.
You can update metadata for an archived object
by specifying its generation in your request.
To ensure safe read-modify-write semantics,
you can use a metageneration-match
precondition.
Using this precondition causes the update
to fail if the metadata you're attempting to update
was changed between the time you read the metadata and the time
you sent the update.
Now, all of this sounds pretty abstract, so let's
explore an example.
Let's see what happens to the file cat in a bucket
with object versioning enabled as you overwrite, update, move,
and delete the file.
You start by uploading an image called cat.
When you first upload cat to Cloud Storage,
it receives a generation number and a metageneration number.
In this example, the generation number is this.
Because the object is new, the metageneration number is 1.
Cat receives generation and metageneration numbers
even though object versioning is not enabled.
For instructions, see the documentation
for viewing the object metadata linked below.
Now, you decide to enable object versioning for your bucket.
This doesn't affect the generation or metageneration
numbers of cat.
But what about when you update the metadata?
Say you update the metadata for cat
by adding a custom metadata--
color, black.
Updating metadata causes the metageneration value of cat
to increase, in this case, from 1 to 2.
However, the object itself remains unchanged.
So Cloud Storage continues to store only one version of cat,
and the version still has the same generation number.
Now you upload a new version of cat
to your Cloud Storage bucket.
When you do so, object versioning
moves the existing cat object into an archived state.
The archived version retains the same storage class and metadata
it previously had.
The archived version appears only if you
perform a versioned listing.
It does not appear in the normal listing commands.
The archived version is now referenced like this.
Meanwhile, the newly uploaded cat
becomes the live version of the object.
This new cat gets its own generation number.
It also gets its own metadata and a metageneration number
of 1, which means it does not contain
the color black metadata unless you specify it.
When you access or modify cat, this
is the version that's used.
You can alternatively refer to this version of cat
using its generation number.
For example, when using the gsutil tool,
you would refer to it with this file name.
What if I decide to move cat to chonker?
Now when I view the archived versions,
I find that cat is now fully archived.
The metageneration number for chonker
is 1 even though there were two versions of cat.
When moving an object in Cloud Storage,
you're actually making a copy, and then deleting
the old version.
This new object doesn't retain the versioning data
of the old one.
OK.
You've decided you prefer dogs, so you delete chonker.
When you do this, the version that had this generation number
becomes archived.
Your bucket now contains two archived version
of cat and no live versions.
You can still refer to either archived version
by using its generation number, but if you
try to access cat without a generation number, it fails.
Similarly, a normal object listing of the bucket
will not show cat as one of the objects in the bucket.
For information on listing archived versions of objects,
see Listing Archived Object Versions, linked below.
You disable object versioning, which
stops future object archiving.
Existing archived versions of objects
remain in Cloud Storage.
And even though object versioning is disabled,
both cat versions remain stored in your bucket
until you delete them, either manually
using the command at gsutil rm or through using
Object Lifecycle Management, which is a topic for a totally
different video.
Even with object versioning disabled,
you can restore one of the existing archived versions
by making a copy of it.
To do so simply named the copy you make cat.
Once you do this, your bucket has three versions
of cat, the two archived versions and the one
live version that came from making a copy.
And there you go.
You can now manage versioning on your own Cloud buckets.
On a side note, do keep in mind that enabling object versioning
increases storage costs.
This can be partially reduced by configuring Object Lifecycle
Management to delete older object versions,
but that's for another episode.
If you'd like to know more about managing object versioning,
check out the links in the description.
Don't forget to subscribe, give us a Like,
and tell us what you want to learn about Google Cloud
Storage.
Thanks for joining us on this quick Byte of Cloud Storage.
See you next time.
[MUSIC PLAYING]