Skip to main content

Object Versioning in Google Cloud Storage

Hands-On Lab


Photo of Matthew Ulasien

Matthew Ulasien

Team Lead Google Cloud in Content





In this hands-on lab, we will enable versioning in a Cloud Storage bucket that is already created for you. We will then experiment with archiving objects, converting archived objects to a live status, and working with managing multiple versions of the same file.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

In this hands-on lab, we are going to enable versioning on a Cloud Storage bucket, which will protect files from being deleted or overwritten.

First, let's enter Cloud Storage from the web console by going to the top left menu and select Storage - Storage.

A Cloud Storage bucket has already been created for you by the name of (PROJECT-ID)-versioning-lab. Click the bucket to go inside of it. Additionally, I highly recommend copying and pasting the bucket name in a text editor for easy reference, as we will call upon it later in this lab.

Open Cloud Shell by clicking the Cloud Shell icon in the top right.

Working with versioning is 100% handled in command line, we are only going to use the web console for reference.

In the Cloud Shell, check the current versioning policy of our bucket:

gsutil versioning get gs://(PROJECT-ID)-versioning-lab
  • IMPORTANT - substitute the actual name of your bucket for the above and through the rest of this lab.

You will see that versioning is current Suspended (i.e. turned off). If you were to delete or overwrite an object in this bucket, it would be erased and can not be recovered. Let's fix that.

Enable versioning in the storage bucket:

gsutil versioning set on gs://(PROJECT-ID)-versioning-lab

Let's now check the versioning policy to make sure it is turned on:

gsutil versioning get gs://(PROJECT-ID)-versioning-lab

It should now be set to Enabled (i.e. turned on).

Now we are going to create a local file in Cloud Shell, copy it to the bucket, then delete the object. With versioning enabled, it should still be archived. We will then make the archived object live again.

Create an empty local file:

touch emptyfile

Copy the empty file to the cloud storage bucket:

gsutil cp emptyfile  gs://(PROJECT-ID)-versioning-lab

Refresh the bucket in the web console, the object 'emptyfile' should be there.

Delete the emptyfile object using the web console.

Now, according to the web console, the object is gone....or is it?

Back in Cloud Shell, view the contents of the bucket by typing:

gsutil ls gs://(PROJECT-ID)-versioning-lab

Looks empty, doesn't it? This time, let's do a detailed listing of the directory contents by using the ls -a option:

gsutil ls -a gs://(PROJECT-ID)-versioning-lab

You will now see the emptyfile object we deleted. It is currently archived. The very long number after it is its generation number.

Let's convert the file from an archived to a live state. Use the gsutil mv commmand to 'move' the file to a live state:

gsutil mv gs://(PROJECT-ID)-versioning-lab/emptyfile#(GENERATION_NUMBER) gs://(PROJECT-ID)-versioning-lab/emptyfile

When this is complete, refresh your web console again and the empty file should have now returned.

Back in the Cloud Shell, do another gsutil ls -a command:

gsutil ls -a gs://(PROJECT-ID)-versioning-lab

The same emptyfile object is still there, but this time it has a different generation number. What happened is that when we 'moved' the archived file to a live state, it create a copy of the file as the live version, and deleted the archived version. If we wanted to leave the archived copy behind, we would use gsutil cp instead of gsutil mv

Next, let's do something different. From Cloud Shell, create a text file by typing:

vim file.txt

In the text file, simply type 'Version 1', then save and close the text file.

Copy this file to our storage bucket:

gsutil cp file.txt gs://(PROJECT-ID)-versioning-lab

Refresh the web console, and click on the file.txt link, which should open a new tab that simply says 'Version 1'.

Back in Cloud Shell, open the same text file in vim:

vim file.txt

This time, change the 'Version 1' string to 'Version 2'. Save and exit.

Copy the same (now edited) file.txt file to our storage bucket:

gsutil cp file.txt gs://(PROJECT-ID)-versioning-lab

In the web console, refresh again, and again click on the file.txt object. It will now open to a tab that says "Version 2".

Back in Cloud Shell, get a detailed listing of the bucket contents:

gsutil ls -a gs://(PROJECT-ID)-versioning-lab

Notice that there are two versions of file.txt, the lower one with the higher generation number is the live version, and the upper one is the archived version.

Finally, let's promote our original 'version 1' version of our file to be the new live version while keeping the original archived version:

gsutil cp gs://(PROJECT-ID)-versioning-lab/file.txt#(LOWER_GENERATION_NUMBER) gs://(PROJECT-ID)-versioning-lab/file.txt

Once again, refresh the web console, click on file.txt, and it should be back to 'Version 1'. And if you were to do one more gsutil ls -a lookup on the storage bucket, you would now see three versions of our file.txt.