Which storage class do you recommend that I use?
Please ensure you have read through the Google documentation on storage classes here: https://cloud.google.com/storage/docs/storage-classes
Ultimately, while the best storage class for your situation depends on how often you intend to access the data in storage, we enforce Autoclass or Standard GCP classes, to minimise unexpected spikes in backup costs.
CloudM Backup accesses data in cloud storage in the following scenarios:
- Backup operations
- Restore operations
- Purge operations
The choice between these two depends on how often you expect to perform the above operations.
We recommend that you use the Google Cloud Storage price calculator here: https://cloud.google.com/products/calculator
Will CloudM Backup cause any additional charges to be applied to my Google Cloud Storage account?
For a full overview of how Google Cloud Storage pricing works, please see their official documentation: https://cloud.google.com/storage/pricing
Data storage and data retrieval costs are covered in the answer above and completely rely on the storage class you intend to use and how much data you intend to store.
Network costs occur whenever data is read from cloud storage, also known as egress. Egress charges from Google Cloud Storage should be minimal unless restoring very large amounts of data per month. A full egress pricing breakdown can be seen here: https://cloud.google.com/storage/pricing#network-egress
Operations costs may occur as CloudM Backup does use some class A and class B operations. However each GCS account has a free quota of operations per month and the amount of operations used by CloudM Backup depends entirely on how the product is used.
Below is a breakdown of all of the class A and class B operations used by CloudM Backup:
Class A
Operation |
Usage |
storage.*.insert |
Once to create the user file in cloud storage NOTE: This operation wont run for deltas, just the initial backup. Twice for emails - once to create the blob file for each email and once to create the JSON for each email. Twice for files - once to create the blob file for each file and once to create the JSON file for each file. Three times for calendars - once to create the calendar, for each calendar and twice for creating the blob file and JSON file for each appointment in the calendar. |
storage.*.list |
Once per 1,000 already migrated emails for pre-existing checks, with a minimum of 1 operation. Once per 1,000 already migrated Google Hangouts chats (legacy code) Once per 1,000 already migrated calendars, with a minimum of 1 operation. Once per 1,000 already migrated appointments for pre-existing checks, with a minimum of 1 operation. Once per 1,000 already migrated files, with a minimum of 1 operation. NOTE: This operation wont run for deltas, just the initial backup. |
Class B
Operation |
Usage |
storage.*.get |
Once for emails, to get the just-uploaded blob file for MD5 checksum verification for each email. Once for files, to get the just uploaded blob file for MD5 checksum verification for each file. |
Example Breakdown:
For a user with 1 email, 1 calendar, 1 appointment, & 1 file, assuming the user has never been backed up:
-
User File:
- 1 class A operation to create the user file.
-
Email Backup:
- 2 Class A operations for pre-existing checks (minimum of 1 list object operation for emails and 1 for chats).
- 2 Class A operations to upload the email (blob + JSON file creation).
- 1 Class B operation to get the just-uploaded blob file for MD5 checksum verification.
-
Calendar Backup:
- 2 Class A operations for pre-existing checks (minimum of 1 list object operation for calendars and 1 for appointments).
- 1 Class A operation to create the calendar.
- 2 Class A operations to upload the appointment (blob + JSON file creation).
-
File Backup:
- 1 Class A operation for pre-existing checks (minimum of 1 list object operation for files).
- 2 Class A operations to upload the file (blob + JSON file creation).
- 1 Class B operation to get the just-uploaded blob file for MD5 checksum verification.