Skip to content
Notifications
Clear all

Troubleshooting: Why is my GCP snapshot taking so long?

1 Posts
1 Users
0 Reactions
3 Views
(@dragonrider)
Reputable Member
Joined: 1 week ago
Posts: 117
Topic starter   [#7972]

Hey everyone, been wrestling with something super frustrating this week and figured this was the best place to bring it. I'm trying to migrate a pretty hefty PostgreSQL database (around 4 TB) from a Compute Engine instance to Cloud SQL, and I'm using persistent disk snapshots as the recommended method. The initial snapshot creation is absolutely crawlingβ€”we're talking an estimated 20+ hours for the first one. My instance is an n2-standard-8, and the disk is a zonal balanced PD.

I love GCP, but this wait is throwing a huge wrench in my migration timeline. I've done similar ops on AWS (EBS snapshots) and it never felt this slow for the initial capture. So I'm diving deep into the "why" and would love to compare notes or get proven strategies from the community.

Here's what I've already checked or tried:
* **Disk activity:** Made sure my application load is minimal during the snapshot. IOPS and throughput aren't pegged.
* **Snapshot location:** It's set to multi-region, which I know adds some overhead, but the docs suggest it shouldn't be this dramatic for the initial.
* **First vs incremental:** I understand the first snapshot is a full copy of all blocks, while subsequent ones are incremental. My question is about this painful first step.

My main theories and questions for you all:
* Is the performance bottleneck here more about the **network egress** from the disk to the snapshot service? Would switching to a regional snapshot location drastically cut the time?
* Does the **disk type** itself (balanced vs SSD) significantly impact snapshot creation speed, or is it purely about the volume of changed blocks? I was on a budget with balanced, but maybe that's a false economy for this task.
* What's the real-world **latency difference** you've seen between zonal, regional, and multi-region snapshots for that initial creation on a multi-terabyte disk?
* Has anyone cooked up a clever **workflow** for this? For example, taking a snapshot of a smaller boot disk, creating a new instance from it, and then attaching the massive data disk as a secondary to snapshot it separately?

I'm all about product-led growth and smooth user migrations, and this snapshot speed is a critical path variable. I'll be running a few controlled tests this week (different disk types, different locations) and will report back with my own cost-per-unit and time numbers. But I'd kill for your war stories and data first!

🔥


Try everything, keep what works.


   
Quote