Disks, Snapshots & Images
Storage attached to VMs. Know the disk types, where each is scoped, and how snapshots/images differ.
Disk types
- Zonal Persistent Disk - standard durable block storage in one zone. Types:
pd-standard(HDD),pd-balanced,pd-ssd,pd-extreme. - Regional Persistent Disk - synchronously replicated across two zones in a region for HA (failover). Costs ~2x zonal.
- Hyperdisk - newest, decouples capacity/IOPS/throughput so you tune each independently; highest performance.
- Local SSD - physically attached, extreme IOPS/low latency, but ephemeral: data is lost on stop/terminate/live-migrate. Not for durable data.
A Persistent Disk is a network-attached virtual block device, not physically attached to the machine - that separation is why it survives VM termination. Its data is distributed across several physical disks, so redundancy is built in.
- A VM boot disk is a Persistent Disk (survives instance deletion only if "keep disk" / delete-rule set to keep). It must be a Persistent Disk (default 10 GB
pd-standard); Local SSD cannot be a boot disk. - Persistent Disk resizes up only, and online (no detach); you then grow the filesystem.
- A PD can be attached read-only to multiple VMs at once - cheaper way to share static data than replicating it to a separate disk per instance.
- Regional PD = 2-zone sync replication; used for cross-zone failover.
- Standard and SSD PDs size up to 257 TB per instance; performance scales with each GB allocated.
Local SSD numbers: each Local SSD is 375 GB; attach up to 24 partitions for 9 TB per instance. Data survives a reset but not a stop or terminate (Local SSDs cannot be reattached to another VM).
Which persistent disk type
RAM disk
A RAM disk (tmpfs) stores data in memory - the fastest option, for small data structures needing a fast scratch disk or cache. It is very volatile (erased on stop/restart), so use a high-memory VM and back it up to a Persistent Disk.
Encryption at rest
Compute Engine encrypts all data at rest by default, Google-managed with no action from you. To control the keys yourself:
Disk options at a glance
Same maximum capacity either way, so it is a cost-vs-performance call: pd-ssd gives more IOPS per dollar, pd-standard (HDD) gives more capacity per dollar.
Never store data you can't lose on Local SSD. It is wiped on stop, host maintenance, or termination. Use it for caches, scratch, swap - not databases.
How many disks can I attach
A VM's throughput scales with its core count, and Disk I/O and network egress/ingress share that same bandwidth. Piling on more attached drives for high Disk I/O will compete with your network traffic - watch this when adding many disks.
Persistent disk vs a physical disk
Because a PD is a virtual networked device, the management chores of a hardware disk disappear:
- Partitioning
- Repartition disk
- Reformat
- Redundant disk arrays
- Subvolume management and snapshots
- Encrypt files before write to disk
- Single file system is best
- Resize (grow) disks
- Resize file system
- Built-in snapshot service
- Automatic encryption
Formatting and mounting a new data disk
A freshly created blank persistent disk is attached but empty - it has no filesystem, so the OS can't use it until you format and mount it. (A disk restored from a snapshot or created from an image already has one - skip formatting.)
- An attached disk shows up at
/dev/disk/by-id/google-<DISK_NAME>, where<DISK_NAME>is the disk's name (or--device-nameif you set one). Use this stable path, not/dev/sdb, which can shift. - Workflow on the VM:
mkfsa filesystem → create a mount point →mountit. Add an/etc/fstabentry so it re-mounts on reboot.
Only run mkfs on a blank disk. Formatting a disk restored from a snapshot destroys the restored data - just mount those.
Snapshots (global)
- Snapshots are a GLOBAL resource and incremental - you can restore a disk into any region/zone.
- First snapshot is full; subsequent ones store only changed blocks (billed for deltas).
- Use snapshots for backup/DR and moving disks across regions.
- Attach a snapshot schedule (a resource policy) to a disk for automatic, recurring backups with a retention window.
- Persistent disks only - snapshots are not available for Local SSD.
- Incremental and automatically compressed, so regular snapshots are faster and much cheaper than repeatedly imaging the full disk.
- Stored in Cloud Storage, but not in your buckets - they are managed by the snapshot service, so you don't see them as objects.
- A snapshot backs up disk data only - it does not capture VM metadata, tags, or other instance config (a machine image does that).
- Create a snapshot schedule to automatically back up zonal and regional persistent disks on a recurring cadence.
- Restore a snapshot to a new persistent disk in another region or zone of the same project - this is the basis of migrating a VM to a new zone.
- Back up critical data into durable storage to meet availability and recovery requirements.
- Migrate data between zones - e.g. to a disk that can be locally attached in the zone where it's consumed, minimizing latency.
- Transfer to a different disk type - snapshot a
pd-standard(HDD) disk and restore ontopd-ssdto improve I/O performance.
Images
- Images are used to create boot disks for new VMs (and instance templates). Public images (Debian, Ubuntu, Windows) or custom images baked with your software.
- Bundle images into an image family so
--image-familyalways picks the latest.
An image bundles everything needed to boot a VM:
- Boot loader
- Operating system (Linux or Windows)
- File system structure
- Any pre-configured software
- Any other customizations
- Sources: Google, third-party vendors, and the community.
- Linux: CentOS, CoreOS, Debian, RHEL (p), SUSE (p), Ubuntu, openSUSE, FreeBSD.
- Windows: Windows Server 2019 (p), 2016 (p), 2012-r2 (p); SQL Server pre-installed on Windows (p).
- (p) marks a premium image (carries an extra license charge).
Images marked (p) bill a license fee on top of the VM. Charged per second after a 1-minute minimum - except SQL Server images, which are per minute after a 10-minute minimum. The premium price varies by machine type but is global: it does not change by region or zone.
Custom images go beyond baking software:
- Create one from a VM with software pre-approved for your organization already installed.
- Import images from on-prem, a workstation, or another cloud provider - a no-cost service, as simple as installing an agent.
- Share custom images with anyone in your project, or across other projects.
You cannot create a custom image from a boot disk while it's attached to a running instance. So when you plan to build a golden image, disable "Delete boot disk when instance is deleted" (turn off auto-delete) at creation - otherwise deleting the VM takes the disk with it and there's nothing left to image.
Machine images
A machine image is a Compute Engine resource that stores all the configuration, metadata, permissions, and data from one or more disks required to create a VM instance. Where a snapshot backs up a single disk and a custom image captures one boot disk, a machine image captures the whole VM.
- Use it for creation, backup and recovery, and instance cloning.
- It is the most ideal resource for disk backups, instance cloning, and replication.
Which resource fits which scenario:
Moving a VM to another zone/region
You might move a VM for geographical reasons or because a zone is being deprecated. There's no single "move" button - you shut down the VM, recreate it in the destination, and restart it. The recommended mechanism is a machine image:
- Create a machine image of the source VM (captures all disks + config).
- Create a new VM from that machine image in the destination zone/region.
- Update any references to the original VM - e.g. target VMs or target pools that pointed at it.
Two other paths depending on distance:
- Same region, automated:
gcloud compute instances moverelocates the VM for you. It does not update references automatically - you still repoint anything that named the old instance. - Cross region, manual (snapshot-based): snapshot every persistent disk → create disks from those snapshots in the target region → create a new VM → attach the disks → reserve/attach a static IP → update references → delete the originals.
You can move a VM even while it is TERMINATED, and Shielded VMs using UEFI firmware are movable.
Moving is a recreate, not a relocate. Server-generated properties of the VM and its disks (internal IPs, resource IDs, etc.) change, so anything referencing the old instance must be repointed. The name/zone/CPU-platform were never mutable in place - see VM lifecycle.