object-versi-26-38cc91-versioning-lab
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.
