In this video, you will learn about versioning support that is available in objects Storage bucket. To begin with, let's look at the console. We're in ulter bucket level. When you create a bucket itself, you have the ability whether you want to have it enabled by default it is disabled. For example, if I pick the case of the bucket I have created here, versioning is disabled, and as a result, if I upload a file with the name which is already existing, it will overwrite the file, so the old version that is in the bucket will be deleted and a latest copy will be kept, so this is the latest copy of the object. History is not maintained. It doesn't bother but just overwrites it. Similarly, if you go and delete a file, the file gets completely deleted, the object gets completely deleted and it is non-recoverable. Whereas, if you enable versioning at a bucket level, remember versioning is at a bucket level. Then you will get a new slider, which gives you the ability to see the liter objects also, why? For example, after you have enabled versioning, if you go and delete a file or an object, please remember from this option, that file is no more visible. But because I've enabled versions, I can say show deleted objects, and we see that there is a deleted object, and if I expand this, it says there is a Delete marker available. If you go and delete the Delete marker, please remember the object would be still back available. I can go back and delete the object again, and as a result, the object is no more visible under the standard look, but if I enable it, I see that deleted file is still available, and if I want, I can download the object from here. But remember, there is a metadata that is stored in the form of a Delete marker, whereas the actual file is still kept. You are charged farthest Storage, farther total amount of space consumed by you. This comes in of help from a Beta archival compliance requirements perspective so that you don't need to worry about losing data, or if you have to be compliant with certain regulatory requirements where data should not be deleted for a certain amount of time, this will take care of it to a certain extent. Whereas, if you landed up uploading a file which is already present with the same name, now it will not prompt far, it will be overwritten instead. Once the file is uploaded, you will see that there are multiple versions of the same object available. In this case, it is actually the same file I've uploaded twice. But remember, there is the latest version which is the last uploaded file that you uploaded. This is what versioning is all about. It gives you Data Protection. You enable it a bucket level. Automatically, new versions are created whenever you upload files with a name of an object that is already available, and one is the latest version, there will always be a latest version for an object in a bucket, and it might have zero history or more than one previous versions available. Now what you need to understand is, what is the relationship or interaction of versioning with other features? We already saw what happens if you delete a file, Delete marker is created, but you might have multiple versions of the same file, you can go and delete the version, the files, the old files can be deleted, the current file will still be available for access. If you perform re-encryption of your bucket, which is something you can do by setting an encryption key, remember, when you do that, the bucket and all its objects are going to be re-encrypted, and when we do re-encryption, it also re-encrypts the current version as well as the existing previous versions. From a lifecycle management perspective, it only archives objects of the current version, and when it deletes objects, it deletes an object and the current object becomes a version by itself with the Delete marker creator because you had a hamming versioning in place when lifecycle delete some object, just a Delete marker is added. When you enable the copy feature at an object level, for example, if you remember, you had the ability to go to a particular object and copy it to another region, when you do that, copy is happening only at the latest version that is available, so the history versions are not copied. If you want them to be copied, you need to explicitly make them there and it becomes a new object in the destination region. Replication takes care of keeping your bucket in one region to have data replicated to another region, which is the fundamental idea there, and if you have replication enabled at your bucket level, remember, it will not replicate previous versions, and you cannot enable versioning on the destination bucket, so what is getting replicated right now is the ones that get replicated to the destination, and you cannot add retention rules, which is a feature that we have to see in the next video. You cannot have retention rules along with versioning at a bucket level, so these are some of the important things to note when you work with objects storage, versioning as such.
