You are managing a set of Cloud SQL databases in Google Cloud. Regulations require that database backups reside in the region where the database is created. You want to minimize operational costs and administrative effort. What should you do?
A.
Configure the automated backups to use a regional Cloud Storage bucket as a custom location.
B.
Use the default configuration for the automated backups location.
C.
Disable automated backups, and create an on-demand backup routine to a regional Cloud Storage bucket.
D.
Disable automated backups, and configure serverless exports to a regional Cloud Storage bucket.
Let's eliminate:
B - defaul is multi-regional even if your instance is regional
C and D - you don't need to disable automated backups, this will increase administrative efforts
All you need to do is to edit your backups and choose to store them in the region that you want instead of multi-regional. A is the answer.
All of the answers are wrong, but A is the least wrong.
B is wrong because the default is multi-region.
C and D are wrong because there's no need to disable automatic backups.
You want automatic backups with a custom region, but it's not a Cloud Storage bucket. So just ignore the reference to Cloud Storage and go with A.
in default two option - Click Multi-region (default) or Region.
In the Google Cloud console, go to the Cloud SQL Instances page.
Go to Cloud SQL Instances
To open the Overview page of an instance, click the instance name.
From the SQL navigation menu, select Backups.
Next to Settings, click Edit.
In the Automated Backups section, expand Advanced Options.
Click Multi-region (default) or Region.
Select the location from the Location drop-down menu.
Click Save.
https://cloud.google.com/sql/docs/mysql/backup-recovery/backing-up#locationbackups
Cloud SQL lets you select a custom location for your backup data. This is useful if your organization needs to comply with data residency regulations that require you to keep your backups within a specific geographic boundary. If your organization has this type of requirement, it probably uses a Resource Location Restriction organizational policy.
A
https://cloud.google.com/sql/docs/mysql/backup-recovery/backing-up#locationbackups
You can use a custom location for on-demand and automatic backups. For a complete list of valid location values, see the Instance locations.
A
"""
Where backups are stored
Backups locations include:
Default locations that Cloud SQL selects, based on the location of the original instance.
Custom locations that you choose when you do not want to use the default location.
"""
https://cloud.google.com/sql/docs/mysql/backup-recovery/backups
"""
Set a custom location for backups
Only use a custom backup location if required by regulation. If not required, use the default multi-region backup location.
You can use a custom location for on-demand and automatic backups.
"""
https://cloud.google.com/sql/docs/mysql/backup-recovery/backing-up#locationbackups
C.
You cannot configure a custom location for automatic backups. A is wrong. The default option for automatic backups is multi-region. B is wrong. The question specifically mentions backups not exports, so eliminate D. That leaves C which involves manual effort, but it does keep the data in the correct region.
A - https://cloud.google.com/sql/docs/mysql/backup-recovery/backups#default-backup-location
"If you do not specify a storage location, your backups are stored in the multiregion that is geographically closest to the location of your Cloud SQL instance."
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
chelbsik
Highly Voted 1 year, 10 months ago887ad17
3 months agoSteve8512
Most Recent 4 weeks, 1 day agosky09
4 months, 2 weeks agosky09
4 months, 2 weeks agoPime13
6 months agoDPonly
1 year, 1 month agopico
1 year, 2 months agoabsero1609
1 year, 6 months agodynamic_dba
1 year, 7 months agoH_S
1 year, 8 months agoH_S
1 year, 8 months agomarpayer
1 year, 9 months agopk349
1 year, 10 months ago