Fast MySQL Database Backups Without Harming Disk Performance

PCA By islever Editorial Last updated

Configuring individual storage systems. Interacting with Google Cloud programmatically.

Short answer

B Stage the mysqldump output on a Local SSD volume for maximum backup speed, then copy it to a Cloud Storage bucket with gsutil.

Question

Your company runs several databases on a single MySQL instance. They need to take backups of a specific database at regular intervals. The backup activity
needs to complete as quickly as possible and cannot be allowed to impact disk performance.
How should you configure the storage?
  1. Configure a cron job to use the gcloud tool to take regular backups using persistent disk snapshots.
  2. Mount a Local SSD volume as the backup location. After the backup is complete, use gsutil to move the backup to Google Cloud Storage. Correct Answer
  3. Use gcsfise to mount a Google Cloud Storage bucket as a volume directly on the instance and write backups to the mounted location using mysqldump.
  4. Mount additional persistent disk volumes onto each virtual machine (VM) instance in a RAID10 array and use LVM to create snapshots to send to Cloud Storage

Key Takeaways

The question tests which storage tier absorbs backup write I/O; the trap is picking gcsfuse-mounted Cloud Storage, which streams backups slowly over the network and keeps the production database under load longer.

This Google Cloud PCA question asks how to back up a single MySQL database on a shared instance quickly, without degrading persistent disk performance. The correct design stages the mysqldump output on a locally attached SSD and then copies it to a Cloud Storage bucket with gsutil.

Common mistake: Option C is the most tempting wrong answer because gcsfuse avoids intermediate storage and mysqldump can target one database, but writing directly to Cloud Storage through a FUSE mount is far slower than Local SSD I/O and extends the window during which the source database is being read.

Expert Analysis

Why the Answer Is Correct

Option B matches Google's own documented best practice for database backups on Compute Engine: stage the backup on a Local SSD and then push it to a Cloud Storage bucket. Local SSDs are physically attached to the host running the VM and deliver very high IOPS and low latency, so a mysqldump of a specific database finishes quickly, minimizing the time the production MySQL instance spends reading data for the backup. Because the write goes to the local device rather than the boot/data persistent disk, the persistent volumes serving production queries see essentially no additional write pressure, satisfying the "cannot be allowed to impact disk performance" constraint. Once staged, gsutil (or a lifecycle/transfer step) moves the file to Cloud Storage for durability, giving you both speed and long-term, redundant retention.

Why the Other Options Are Wrong

Option A uses persistent disk snapshots, which capture an entire disk image rather than one selected database, and the snapshot read activity is performed against the same persistent disk that serves production traffic — exactly the disk impact the requirement forbids. Option C writes through gcsfuse directly into a Cloud Storage bucket; FUSE-backed writes are network-bound and much slower than local SSD writes, so the backup runs longer and the database remains under sustained read load, which is why commenters flagged "quickly as possible" as the deciding phrase. Option D adds RAID10 volumes plus LVM snapshot plumbing on persistent disks, which adds cost and operational complexity without removing the backup I/O from the production disks, and LVM snapshots still stress the underlying volumes during creation. It also over-provisions storage for every VM when only one database on one instance needs periodic backup.

Community Comment Notes

The community converged strongly on B, with Hannibal1969 explaining that "GCFUSE will write to GCS which is much slower than writing directly to an added SSD" and that it "would also execute reads for a longer period on the production" database. Rathish added that while Local SSD plus gcsfuse could combine speed and direct-to-GCS durability, the phrase "needs to complete as quickly as p..." pushes the answer toward staging on Local SSD. syu31svc and kaush both cited Google's documented guidance to "use the local SSD to stage your backups and then push them to a Cloud Storage bucket." A minority, AD3, argued for C on the grounds that "the mysqldmp provides option to backup specific database," but that confuses the tool choice (mysqldump, used in both B and C) with the storage design, which is what the question actually asks.

Official Reference

https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up

This link opens the official vendor documentation in a new tab.

Exam Strategy

Read the non-functional constraints first — "as quickly as possible" and "cannot impact disk performance" — and map them to the fastest local storage tier that is then offloaded to durable object storage. Eliminate any option whose I/O lands on the same persistent disk serving production or that streams over the network for the entire backup window.

Frequently Asked Questions

Why is gcsfuse-mounted Cloud Storage (option C) wrong for fast MySQL backups?

Writing through gcsfuse is network-bound and far slower than Local SSD I/O, so the backup runs longer and the production database stays under read load for more time. Local SSD staging plus gsutil gives the fastest completion, which the question explicitly demands.

Why not use persistent disk snapshots to back up just one database?

Cloud Persistent Disk snapshots capture an entire disk image, not a single logical database, and the snapshot process reads from the same persistent disk serving production traffic. That violates the requirement that backup activity must not impact disk performance.

More PCA FAQ →

Discussion 142 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 142

  1. hannibal1969 👍 54
    I think it's B. If you use a tool like GCFUSE it will write immediatly to GCS which is a cost benefit because you don't need intermediate storage. In this case however "Quickly as possible" key for understanding. GCFUSE will write to GCS which is much slower than writing directly to an added SSD. During the write to GCS it would also execute reads for a longer period on the production database. Therefor writing to the extra SSD would be my recommended solution. Offloading from the SSD to GCS would not impact the running database because the data is already separated.
  2. Rathish 👍 16
    Ans: B Persistent Disk snapshot not required: "They need to take backups of a specific database at regular intervals." "The backup activity needs to complete as quickly as possible and cannot be allowed to impact disk performance." This can be achieved by using both Local SSD & GCS Fuse (mounting GCS as directory), but as the question stats needs to complete as quickly as possible. General Rule: Any addition of components introduce a latency. I could not get write throughput of GCS & Local SSD, even if we consider both provides same throughput, streaming data through network to GCS Bucket introduce latency. Attached Local SSD has advantage in this case, since there is no network involved. From Local SSD to GCS bucket - copy job does not impact the mysql data disk.
  3. JJu 👍 10
    i think answer is B.
  4. kaush 👍 7
    Best practice: Have a plan for backups and perform backups regularly. Ola Hallengren's site provides a good starting point for understanding how to implement a solid backup and maintenance plan. When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket.
  5. syu31svc 👍 7
    Answer is B hands down --> https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up Use the local SSD to stage your backups and then push them to a Cloud Storage bucket.
Show 25 more comments
  1. KouShikyou 👍 7
    In case of SQL server, B is correct. Does it also work for MySQL? https://cloud.google.com/compute/docs/instances/sql-server/best-practices
  2. AD3 👍 6
    C is the correct answer because it's asked that "backup specific database". The mysqldmp provides option to backup specific database.
  3. tartar 👍 6
    B is ok
  4. omermahgoub 👍 5
    Option B is the most appropriate solution in this case. Mounting a Local SSD volume as the backup location will allow the backups to be taken quickly and efficiently, as Local SSDs have very high I/O performance and low latencies. Additionally, using gsutil to move the backups to Google Cloud Storage after they have been taken will provide a secure and durable storage location for the backups. A, configuring a cron job to use the gcloud tool to take regular backups using persistent disk snapshots, may not be the most efficient option because persistent disks have relatively lower I/O performance compared to Local SSDs. C, using gcsfuse to mount a Google Cloud Storage bucket as a volume directly on the instance and writing the backups to the mounted location using mysqldump, may not be the most efficient option because the backups would need to be transferred over the network, which could impact the performance of the backups.
  5. Ric350 👍 5
    B - I think this will clear things up. Local SSD is ATTACHED when CREATING the VM. The local SSDs are just LOCATED (on the physical host) where the VM is running. See here. https://cloud.google.com/compute/docs/disks/add-local-ssd#create_local_ssd You can have a VM with locally attached SSD in an unformatted and unmounted state or just not mounted! Maybe it was umounted and now needs to be re-mounted? Answer B says to MOUNT the local SSD. MOUNTING the SSD is done when the VM is RUNNING! We need to assume the VM was built with locally attached SSD but not formatted and mounted yet. See here. https://cloud.google.com/compute/docs/disks/add-local-ssd#format_and_mount_a_local_ssd_device!
  6. sekhrivijay 👍 5
    B is correct Documentation from GCP https://cloud.google.com/compute/docs/instances/sql-server/best-practices Best practice: Have a plan for backups and perform backups regularly. Ola Hallengren's site provides a good starting point for understanding how to implement a solid backup and maintenance plan. When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket.
  7. VishalB 👍 5
    Correct Ans B - https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket.
  8. cmamiusa 👍 5 Answered B
    Backing up Best practice: https://cloud.google.com/compute/docs/instances/sql-server/best-practices When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket.
  9. clouddude 👍 5
    I choose C because it's the only answer that let's you dump one specific database.
  10. blitzzzz 👍 5
    who what to backup to a local SSD. If your instance is down, you lost all data.
  11. yeahlon 👍 4 Answered B
    Backing up Best practice: Have a plan for backups and perform backups regularly. Ola Hallengren's site provides a good starting point for understanding how to implement a solid backup and maintenance plan. When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket. https://cloud.google.com/compute/docs/instances/sql-server/best-practices
  12. Pradeepkumar 👍 4
    https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket. Though it is mentioned for SQL Server, the best practices are common for most of the databases. Also it is assumed that the Local SSD are already mounted while creating the VM
  13. deaglee 👍 4
    I'd go for B, C seems wrong because: 1. mportant: Cloud Storage FUSE is a Google-developed and community-supported open-source tool, written in Go and hosted on GitHub. Cloud Storage FUSE is governed solely by the Apache License and not by any other terms or conditions. It is distributed as-is, without warranties of any kind. 2. Performance: Cloud Storage FUSE has much higher latency than a local file system.
  14. cloudryder 👍 4
    The requirement said "as quickly as possible and cannot be allowed to impact disk performance", and anything other than A will impact disk performance and cannot be as fast as A.
  15. jchacana 👍 4
    My reason to say C is that in order to perform a "specific database backup" you need to go with a mysqldump command. Other alternatives are all or nothing
  16. H_S 👍 4 Answered C
    The only way to have a specific data base backup is mysqldump mates trust me I am a data person it can't be anything else than C
  17. raf2121 👍 4
    Point for Discussion Can local SSD be mounted in a running instance.
  18. 2g 👍 4
    answer: C Please replace gcsfise by gcsfuse
  19. Ziegler 👍 3
    A is the answer and the preferred GCP approach. B and C are good candidates but unfortunately for the following reasons - Local SSDs can only be created during instance creation process and the volume is good for data that is ephemeral in nature (B is wrong for that reason); gcsfuse is not a GCP supported service but a community supported service that you use at your own peril (C is a wrong choice as well). Considering that we are talking of database backup which is expected to be reliable, using a cron job to schedule backup to cloud (using gsutil). This is an effective GCP file transfer supported service. https://cloud.google.com/compute/docs/disks/local-ssd https://cloud.google.com/compute/docs/disks/local-ssd#create_local_ssd https://cloud.google.com/storage/docs/gcs-fuse
  20. JC0926 👍 3 Answered B
    Option B would be the best choice for this scenario. Mounting a Local SSD volume as the backup location would ensure high performance and minimal impact on disk performance, while also allowing for quick backups. After the backup is complete, using gsutil to move the backup to Google Cloud Storage would provide a reliable and secure storage location for the backups. This approach is also cost-effective, as Local SSD volumes are less expensive than persistent disks.
  21. nitinz 👍 3
    Please read the question. The backup activity needs to complete as quickly as possible and __cannot be allowed to impact disk performance__. How should you configure the storage? B. Mount a Local SSD volume as the backup location. After the backup is complete, use gsutil to move the backup to Google Cloud Storage. fuse is slow.... Take backup on SSD which is the fastest way and then use gsutil to copy it over at slow speed of network. Best answer is B
  22. Ric350 👍 3
    Also, When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket. See here under "formatting secondary disks, backing up." https://cloud.google.com/compute/docs/instances/sql-server/best-practices#formatting_secondary_disks
  23. nymets 👍 3
    No, you cannot attach a local SSD after the instance is created. "Because Local SSDs are located on the physical machine where your virtual machine instance is running, they can be created only during the instance creation process." The above is from https://cloud.google.com/compute/docs/disks/local-ssd#formatandmount
  24. Gini 👍 3
    The answers are very confusing but I would choose C as the question states "need to take backups of a specific database", mysqldump allows you to specify the database you want to do a backup. B is a potential answer but it only mentions "backup" which I am afraid it means the whole backup of the instance.
  25. misho 👍 3
    I think the answer is "C" because: in "B" you have to write to the SSD one time and then transfer to GCS in "C" you write directly to GCS There is no way that "B" is faster than "C". Also if you stop the VM instance the local before the dump is transferred to GCS, the dump will be lost.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Multi-Regional vs Regional Cloud Storage for Global Software Downloads

S-grade

Surviving a Zone Outage With SQL Server on GCP

S-grade

Fixing BigQuery connection errors from a Compute Engine VM

S-grade

Moving 75 TB into Cloud Storage with Google-recommended practices

S-grade

Practice All PCA Questions

Access 81 questions with complete answers and detailed explanations.

View Full PCA Practice Test →

← Back to PCA Study Guide