What Are Persistent Disks
Persistent Disks (PD) are Google Cloud's network-attached block storage for Compute Engine VMs: unlike a physical SSD soldered to a server, a persistent disk is a virtual block device backed by distributed storage that lives independently of any single VM. You can detach a persistent disk from one instance and attach it to another, and the disk survives instance deletion (unless you explicitly delete it too), which makes it the standard choice for VM boot disks and any data that needs to outlive the compute instance.
Cricket analogy: It's like a player's personalized kit bag that travels with them between IPL franchises each season, independent of which team they're currently playing for, rather than gear that belongs permanently to one team's locker room.
Disk Types
GCP offers several persistent disk types with different performance and cost profiles: pd-standard uses hard-disk-drive-backed storage and is the cheapest, suited to sequential workloads like batch processing or backups; pd-balanced offers SSD performance at moderate cost and is a sensible default for most VM boot disks; pd-ssd delivers higher IOPS and lower latency for demanding databases; and pd-extreme allows you to explicitly provision a guaranteed IOPS level independent of disk size, for the most latency-sensitive workloads like large transactional databases.
Cricket analogy: It's like choosing between a club-level net bowler (pd-standard, cheap and steady for practice), a state-level pacer (pd-balanced, solid all-round performance), and a genuine international fast bowler like Starc (pd-ssd) for the highest-stakes matches.
# Create a balanced persistent disk and attach it to a VM
gcloud compute disks create data-disk-1 \
--size=200GB \
--type=pd-balanced \
--zone=us-central1-a
gcloud compute instances attach-disk web-server-1 \
--disk=data-disk-1 \
--zone=us-central1-a
# Create a high-performance SSD disk for a database VM
gcloud compute disks create db-disk-1 \
--size=500GB \
--type=pd-ssd \
--zone=us-central1-aSnapshots and Resizing
Persistent disk snapshots are incremental: after the first full snapshot, every subsequent snapshot only stores the blocks that changed, which keeps both storage cost and snapshot time low even for frequent backups. Disks can be resized upward while the VM is running and without downtime, though the underlying file system typically still needs to be grown separately to use the extra space. For high-availability needs, regional persistent disks synchronously replicate data across two zones within a region, so a zone outage doesn't take your disk down with it.
Cricket analogy: It's like a broadcaster only re-recording the highlights that changed since yesterday's edit rather than re-filming the whole day's play, keeping the nightly highlights reel quick to produce even during a five-day Test.
Regional persistent disks synchronously write to two zones before acknowledging the write, giving you a recovery point objective near zero if a zone fails, but at roughly double the cost and slightly higher write latency than a zonal disk.
Attaching and Sharing
By default a persistent disk is attached to a single VM in read-write mode. You can attach the same disk to multiple VMs simultaneously only in read-only mode, which suits distributing static reference data or shared configuration to a fleet of instances, but is unsuitable for any workload that needs concurrent writes from multiple machines — for that, Filestore or a database is the correct tool. Disks are also zonal by default, meaning they can only attach to VMs in the same zone unless you specifically provisioned a regional persistent disk.
Cricket analogy: It's like one master scorecard that the umpire alone can edit during play (read-write, single VM), while every broadcaster's graphics team gets a read-only feed of it to display on screen simultaneously (multi-attach read-only).
- Persistent Disks are network-attached block storage for Compute Engine, independent of any single VM's lifecycle.
- Disk types trade off cost and performance: pd-standard (HDD, cheap), pd-balanced (default SSD), pd-ssd (high performance), pd-extreme (provisioned IOPS).
- Snapshots are incremental after the first, keeping backup cost and time low even for frequent snapshots.
- Disks can be resized upward live without downtime, though the file system must usually be grown separately.
- Regional persistent disks replicate synchronously across two zones for high availability, at roughly double the cost.
- A disk defaults to single-VM read-write attachment; multi-VM attachment is read-only only, unsuitable for concurrent writers.
- Disks are zonal by default and can only attach to VMs in the same zone unless provisioned as regional.
Practice what you learned
1. What happens to a persistent disk by default when its attached VM is deleted?
2. Which disk type lets you provision a guaranteed IOPS level independent of disk size?
3. How do persistent disk snapshots after the first one behave?
4. Can a persistent disk be attached to multiple VMs at the same time for writing?
5. What benefit does a regional persistent disk provide over a zonal one?
Was this page helpful?
You May Also Like
Filestore Basics
How Google Cloud's managed NFS file storage service works — service tiers, mounting, shared multi-VM use cases, and backup versus snapshot protection.
Choosing the Right GCP Storage
A decision framework for picking between Cloud Storage, Persistent Disks, and Filestore based on access pattern, cost, and performance needs.
Cloud Storage Basics
An introduction to Google Cloud Storage's object model — buckets, objects, naming, access control, and the durability and consistency guarantees behind it.