Cloud Storage Features
1. Cloud Storage Features
There are also several features that come with Cloud Storage. We will cover these at a high-level for now because we will soon dive deeper into some of them. Earlier in the course series, we already talked a little about Customer-supplied encryption keys when attaching persistent disks to virtual machines. This allows you to supply your own encryption keys instead of the Google-managed keys, which is also available for Cloud Storage. Cloud Storage also provides Object Lifecycle Management which lets you automatically delete or archive objects. Another feature is object versioning which allows you to maintain multiple versions of objects in your bucket. You are charged for the versions as if they were multiple files, which is something to keep in mind. Cloud Storage also offers directory synchronization so that you can sync a VM directory with a bucket. Object change notifications can be configured for Cloud Storage using Pub/Sub. When enabled, Autoclass manages all aspects of storage classes for a bucket. We will discuss this later. In Cloud Storage, objects are immutable, which means that an uploaded object cannot change throughout its storage lifetime. To support the retrieval of objects that are deleted or overwritten, Cloud Storage offers the Object Versioning feature. Object Versioning can be enabled for a bucket. Once enabled, Cloud Storage creates an archived version of an object each time the live version of the object is overwritten or deleted. The archived version retains the name of the object but is uniquely identified by a generation number as illustrated on this slide by g1. When 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. You can turn versioning on or off for a bucket at any time. Turning versioning off leaves existing object versions in place and causes the bucket to stop accumulating new archived object versions. Google recommends that you use Soft Delete instead of Object Versioning to protect against permanent data loss from accidental or malicious deletions. A link to the Object Versioning documentation can be found in the Course Resources for this module. Soft Delete provides default bucket-level protection for your data from accidental or malicious deletion by preserving all recently deleted objects for a specified period of time. The objects stored in Cloud Storage buckets are immutable. If you overwrite or change the data of an object, Cloud Storage deletes its earlier version and replaces it with a new one. Soft Delete retains all these deleted objects, whether from a delete command or because of an overwrite, essentially capturing all changes made to bucket data for the configured retention duration. When you create a Cloud Storage bucket, the Soft Delete feature is enabled by default with a retention duration of seven days. During the retention duration, you can restore deleted objects, but after the duration ends, Cloud Storage permanently deletes the objects. By updating the bucket's configuration, you can increase the retention duration to 90 days or disable it by setting the retention duration to 0. A link to the Soft Delete documentation can be found in the Course Resources for this module. To support common use cases like setting a Time to Live for objects, archiving older versions of objects, or "downgrading" storage classes of objects to help manage costs, Cloud Storage offers Object Lifecycle Management. You can assign a lifecycle management configuration to a bucket. The configuration is a set of rules that apply to all the objects in the bucket. So when an object meets the criteria of one of the rules, Cloud Storage automatically performs a specified action on the object. Here are some example use cases: First, downgrade the storage class of objects older than a year to Coldline Storage. Second, delete objects created before a specific date. For example, January 1, 2017. Or third, keep only the 3 most recent versions of each object in a bucket with versioning enabled. Object inspection occurs in asynchronous batches, so rules may not be applied immediately. Also, updates to your lifecycle configuration may take up to 24 hours to go into effect. This means that when you change your lifecycle configuration, Object Lifecycle Management may still perform actions based on the old configuration for up to 24 hours. So keep that in mind. A link to the Object Lifecycle Management documentation can be found in the Course Resources for this module. The Object Retention Lock feature lets you set retention configuration on objects within Cloud Storage buckets that have enabled the feature. A retention configuration governs how long the object must be retained and has the option to permanently prevent the retention time from being reduced or removed. This helps you meet data retention regulatory and compliance requirements, such as those associated with FINRA, SEC, and CFTC. This also helps provide Google Cloud immutable storage solutions with leading enterprise backup software vendor partners. A link to the Object Retention Lock documentation can be found in the Course Resources for this module. The Cloud Console allows you to upload individual files to your bucket. But what if you have to upload terabytes or even petabytes of data? There are three services that address this: Transfer Appliance, Storage Transfer Service, and Offline Media Import. Transfer Appliance is a hardware appliance you can use to securely migrate large volumes of data (from hundreds of terabytes up to 1 petabyte) to Google Cloud without disrupting business operations. The images on this slide are transfer appliances. The Storage Transfer Service enables high-performance imports of online data. That data source can be another Cloud Storage bucket, an Amazon S3 bucket, or an HTTP/HTTPS location. Finally, Offline Media Import is a third party service where physical media (such as storage arrays, hard disk drives, tapes, and USB flash drives) is sent to a provider who uploads the data. For more information on these three services, refer to the Course Resources. When you upload an object to Cloud Storage and you receive a success response, the object is immediately available for download and metadata operations from any location where Google offers service. This is true whether you create a new object or overwrite an existing object. Because uploads are strongly consistent, you will never receive a 404 Not Found response or stale data for a read-after-write or read-after-metadata-update operation. Strong global consistency also extends to deletion operations on objects. If a deletion request succeeds, an immediate attempt to download the object or its metadata will result in a 404 Not Found status code. You get the 404 error because the object no longer exists after the delete operation succeeds. Bucket listing is strongly consistent. For example, if you create a bucket, then immediately perform a list buckets operation, the new bucket appears in the returned list of buckets. Finally, object listing is also strongly consistent. For example, if you upload an object to a bucket and then immediately perform a list objects operation, the new object appears in the returned list of objects.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.