-
Object versioning
- When enabled, deleted or overwritten objects are archived
- Enables retrieval of deleted or overwritten objects
- Object maintains name but assigned unique identifier number
- Enabled at bucket level
- Disabled by default
- If versioning is disabled, existing version remain but new ones not created
- No default limit on versions
- Versioning can increase bucket size and cost significantly
- Archived versions retain own ACL which may differ from live object ACL
-
Actions
- List archived versions
- Restore archived versions to live state
- Permanently delete older versions
-
Object lifecycle management
- Set Time to Live (TTL) on an object
- Archive/Delete older versions
- Downgrade storage classes
- Appled to bucket level
- Often used alongside object versioning, but not required
-
Policies
- Downgrade the storage class of objects older than 365 days to cold storage
- Delete objects created before January 1, 2017
- Keep only the 3 most recent versions of each object in a bucket
- Implemented with Rules, Conditions and Actions
- Rules must have all conditions met before executing
- Actions only need one Rule to be met before being executed
-
Lifecycle Management
-
Set of rules that apply to current and future objects in a bucket
- Time to Live (TTL)
- Archiving older versions
- Downgrading storage
- Specified action is automatically performed when objects meets the criteria of rule
-
Actions
- Delete live and/or archived objects. Cannot be undone
- Change the storage class of live and/or archived objects
- Applies to versioned and non-versioned objects
-
Behavior
- At least one condition is required
- Asynchronous regular inspection on each bucket
- Does not rewrite an object when changing its storage class
-
gsutil
-
Operations
- Creating and deleting buckets
- Uploading, downloading and deleting objects
- Listing buckets and objects
- Moving, copying and renaming objects
- Editing object and bucket ACLs
-
Commands
- gsutil cp file.txt gs://mybucket
- gsutil ls -a gs://mybucket
- gsutil -m cp -r gs://mybucket .
- gsutil help cp
- gsutil versioning get gs://<bucket>
- gsutil versioning set on gs://<bucket>
- gsutil ls gs://<bucket>/folder
- gsutil ls -r gs://<bucket>
- gsutil cp <file> gs://<bucket>
- gsutil lifecycle get gs://<bucket> > filename.json
- gsutil lifecycle set filename.json gs://<bucket>
- gsutil rm -r gs://<bucket>
- gsutil mb -l <location> -c <class> gs://<bucket>
- gsutil -m cp -r <files/directory> gs://<bucket>
- gsutil versioning set off gs://<bucket>
- gsutil -m rewrite -r -s NEARLINE gs://<bucket>/* (-m for parallel processing
- gsutil acl ch -d AllUsers:R gs://<bucket>/<object>
- gsutil acl ch -d AllUsers gs://<bucket>/<object>
- gsutil rm -r gs://<bucket>
-
Bucket Lock
- Allows users to configure data retention policies for Cloud Storage bucket
- Policies govern how long objects in a bucket must be retained
- Data retention policies can be locked permanently, preventing delete or modification
- Used for Write Once Read Many (WORM) storage
- Prevents deletion of modification of data for a specified time period
- Helps meet compliance, legal and regulatory requirements for data retention
- Works with all tiers of Cloud Storage
- Lifecycle policies can be applied to automatically move locked data to colder storage classes
-
Retention Policies
- A retention policy can be included when creating a new bucket
- Add a retention policy to an existing bucket
- Ensures objects cannot be deleted or overwitten until they reach the age defined in the policy
- Tracked by retention expiration time metadata
-
Retention Period
- Measured in seconds
- Can be set in days, months or years
- Max is 100 years
-
Retention Policy Locks
- Prevents the policy from ever being removed
- Prevents the retention period from ever being reduced
- Once retention policy is locked, bucket can't be deleted until objects have met the retention period
- Locking a retention policy is irreversible
- Project-wide lien is put in place by Object Storage
-
Object Holds
- Metadata flags that are placed on individual objects
- Objects with holds cannot be deleted
- Event based holds can be used with retention policies to control retention based on events
- Temporary holds can be used for regulatory or legal investigation purposes
- Objects can have one, both or neither
-
Compliance
- Can be used to comply with regulatory requirements
-
Removal
- Locking a retention policy is irreverable
- Once locked, the entire bucket must be deleted in order to remove the retention policy
- All objects must be deleted from the bucket before the bucket can be deleted
- Objects can only be deleted if they have reached the retention period set by the retention policy
-
Transfer
-
Time
- By default gsutil transfers one file at a time
- Each transfer has an overhead which can affect performance
- Large files take a long time to transfer, even with sufficient bandwidth
- The smaller the file, the more the overhead affects the total transfer time
- Slice large files into smaller pieces (composite objects)
- Transfer multiple files at a time with multi-threading
- GCP re-assembles the pieces when the transfer is complete
- gsutil -m cp -r /my-local-dir gs://my-bucket
- gsutil -o GSUtil:parallel_composite_upload_threshold=150M cp ./my-large-fiule gs://my-bucket
- Do not use Nearline/Coldline storage class as this will result in a "modification" fee
-
Performance
- Use "perfdiag" option in gsutil
- Diagnostic only. Does not optimize transfers
- Need to measure performance for standard and optimized transfers
- Test transfers, reading and deleting multiple test files of different sizes to GCS
- Adjust parameters for file size =, multi-threading,number of tests etc, to view results
- gsutil perfdiag gs://my-bucket