Start with the big picture: what a Persistent Disk is, and what it is not.

Persistent Disk, often shortened to PD, is a service that gives your virtual machines block storage. Block storage is the same kind of storage a normal computer uses for its internal drive. The disk looks like a raw, empty drive to the operating system. The operating system then puts a file system on it, which is the organised structure of folders and files that you are used to. The word block simply means that the data is stored and read in small, equal-sized pieces, which makes it very fast and flexible.

The word persistent is the important one. It means the data stays safe even when the virtual machine is stopped, restarted or deleted. A virtual machine is a software computer that Google runs for you on its hardware. These machines can come and go, but a Persistent Disk keeps living on its own until you decide to delete it.

Network storage, not a drive inside the machine

A Persistent Disk is not physically inside the computer that runs your virtual machine. It is a network-attached disk, which means the data lives on separate storage machines in the same data centre, and your virtual machine talks to them over Google’s internal network. This design is the secret of its flexibility. Because the disk is separate, you can detach it from one machine and attach it to another, resize it while it is in use, and copy it without turning anything off.

What it is used for

Almost every Compute Engine virtual machine has a boot disk, which holds the operating system. Many also have extra data disks for databases, application files, logs and backups. Kubernetes clusters on Google Cloud use Persistent Disks to give containers a place to keep data that must survive restarts. Managed products such as Cloud SQL are also built on the same family of network block storage, though Google manages those disks for you.

To understand any tool, first feel the pain it was built to remove.

In a traditional data centre, every server had its own disks screwed into its own case. This worked, but it created a long list of troubles. When a server broke, the data trapped inside it was stuck until someone repaired or replaced the hardware. When a server ran out of space, someone had to buy a bigger disk, open the machine, install it and copy everything over, often at night to avoid disturbing users.

Planning capacity was another headache. You had to guess how much storage each server would need for the next three years and buy accordingly. Guess too low and you faced emergency upgrades. Guess too high and money sat idle inside machines that never used it. Backups were manual chores, and moving an application to a better machine meant long, risky copying.

The four big headaches

Persistent Disk attacks all four. The data is stored redundantly on separate storage machines, so a single hardware failure does not lose it. You can enlarge a disk while it is running. You can detach it and attach it to another machine within the same zone in moments. And you can take snapshots, which are point-in-time backups, with a single request or on an automatic schedule.

A handful of words explain almost everything in Persistent Disk. Learn them well and the rest becomes easy.

Block storage, file system and mount

A raw Persistent Disk is like a blank notebook with numbered pages but no table of contents. The operating system must first create a file system, which acts as the table of contents and the filing rules. Common examples are ext4 and XFS on Linux, and NTFS on Windows. This step is called formatting. After that, the disk must be mounted, which means attached to a folder path so that programs can read and write files there.

Zones and regions

Google Cloud is divided into regions, which are geographic areas such as Mumbai, Iowa or Frankfurt. Each region contains several zones, which are separate data-centre areas with their own power and cooling. A normal Persistent Disk is a zonal resource. It lives in one specific zone, and it can only be attached to virtual machines in that same zone. A regional Persistent Disk keeps copies in two zones of one region, which gives extra protection against a zone failure.

Boot disk and data disk

The boot disk holds the operating system and is required for the machine to start. A data disk is an extra disk for your application’s information. Keeping data on a separate disk from the operating system is a wise habit. You can rebuild the machine from a fresh operating system image and simply reattach the data disk.

Attach, detach and auto-delete

Attaching connects a disk to a virtual machine. Detaching disconnects it without destroying it. Each disk also has an auto-delete setting that says whether the disk should be deleted when its virtual machine is deleted. Boot disks commonly default to auto-delete, while extra data disks are commonly kept. Check this setting on important disks, because it decides whether your data survives the machine.

IOPS, throughput and latency

Three numbers describe disk speed, and you will see them throughout this guide.

Persistent Disk comes in several flavours. Picking the right flavour is the most important decision you will make.

Google offers different Persistent Disk types, each built on different storage technology and priced differently. The names are easy to remember once you know the pattern. The product names below were current at the time of writing, so always confirm the latest list and the machine types that support each one on the official page.

Where Hyperdisk and Local SSD fit

Hyperdisk is a newer family of network block storage in which you choose the capacity, the operations per second and the throughput separately, instead of getting speed mainly from size. Newer machine families are increasingly designed around Hyperdisk, and some support it in addition to or instead of Persistent Disk. Local SSD is different in kind. It is physically attached to the host machine and is extremely fast, but it is temporary and its data does not follow the machine in the same protective way. Use it for scratch data, caches and anything you can rebuild.

Let us look at the main pieces that sit between your application and the stored bytes.

When your program saves a file, the request travels through several layers before the data is safely stored. Knowing these layers helps you explain slow disks, strange errors and sizing limits. The diagram below shows a simplified view.

flowchart LR
  APP["Application or Database"] --> FS["File System in the Guest OS"]
  FS --> BD["Virtual Block Device in the VM"]
  BD --> NET["Google Data Centre Network"]
  NET --> CTRL["Persistent Disk Storage Service"]
  CTRL --> R1[("Storage Replica 1")]
  CTRL --> R2[("Storage Replica 2")]
  CTRL --> R3[("Storage Replica 3")]
  CTRL -.->|"Regional disks only"| Z2["Second Zone Replica Set"]
  CTRL -.->|"Snapshots"| GCS[("Cloud Storage Snapshot Store")]
    

Walking through the diagram

The application asks the file system to save data. The file system turns “save this file” into low-level block requests, such as “write these bytes at this position”. These requests go to a virtual block device inside your virtual machine, which looks like an ordinary disk to the operating system. From there, the request leaves the machine and crosses Google’s internal network to the Persistent Disk storage service.

The storage service is the brain of the system. It decides where the data should live, writes it to several storage replicas on different machines, and only reports success once the data is safely stored. In a regional disk, copies are also kept in a second zone. Snapshots, which are backups taken from the disk, are stored separately in Google’s object storage, so they do not depend on the original disk surviving.

Key components in plain words

One important design idea hides in this picture. Your virtual machine is stateless in spirit, and the disk is the memory. Because the memory lives outside the machine, Google can move, restart or repair the machine without touching your data.

Follow one single save operation from your program to safe storage and back.

Let us trace what happens when a database saves one new order to a Balanced Persistent Disk. The goal is to see where time is spent and where safety is guaranteed.

sequenceDiagram
  participant A as Database
  participant O as Guest OS and File System
  participant V as Virtual Disk Driver
  participant S as PD Storage Service
  participant R as Storage Replicas
  A->>O: Write order record
  O->>V: Block write request
  V->>S: Send request over network
  S->>R: Write to several replicas
  R-->>S: Acknowledge each copy
  S-->>V: Write confirmed
  V-->>O: Complete
  O-->>A: Success returned
    

Step by step

Reads and caching

A read follows a similar path in the opposite direction. The operating system also keeps a page cache, which is a portion of the machine’s memory used to hold recently read file data. If the data you need is already in the cache, the disk is not touched at all, and the answer comes back in microseconds. This is why a machine with generous memory often feels much faster than the raw disk numbers suggest.

Why the flush matters

A flush, sometimes called a sync, forces buffered data out of memory and onto the disk. Without a flush, a machine crash could lose the last few seconds of work that the program believed was saved. Databases flush carefully on purpose, and this is why disk latency has a direct effect on how many transactions per second a database can commit.

Disk speed is shaped by three things at once: the disk, the machine and the way your software uses it.

It surprises many beginners that the performance of a Persistent Disk is not decided by the disk alone. Three limits work together, and the lowest one wins. This is the single most useful idea in this chapter.

Size affects speed

For Standard, Balanced and SSD disks, performance is tied to size. This has a surprising practical effect: sometimes it is sensible to create a larger disk than you need purely to gain performance. A database that needs 200 gigabytes of space but 10,000 operations per second may need a disk several times bigger to unlock that speed. Always compare the cost of a larger disk with the cost of moving to a faster type. Check the current performance tables in the official documentation, because limits are updated as the service evolves.

IOPS or throughput: which one matters?

Practical tuning steps

• Measure first. Use a disk benchmarking tool on a test copy to learn the real limits, rather than trusting guesses.
• Check the machine. Confirm that the machine type allows the disk traffic you need.
• Add memory. A bigger page cache reduces how often the disk is touched.
• Keep requests flowing. Configure applications to issue several requests at once so the disk stays busy.
• Separate workloads. Put the busy database on its own disk, apart from logs and backups, so they do not fight for the same limits.

A worked sizing story

Imagine a small online shop whose database holds 150 gigabytes of data. During a festival sale, the database must handle about eight thousand operations per second. The team first creates a 150 gigabyte Balanced disk, because it matches the data size and the budget is tight. On the first sale day, response times climb, and the monitoring dashboard shows throttled operations above zero for most of the afternoon. The disk is not full, and the machine is not busy, but the disk is simply too small to deliver the speed the database wants.

The team now has three choices. They can grow the disk to a much larger size, which raises the allowed operations and costs more in storage. They can move to an SSD disk type, which gives more operations for each gigabyte. Or they can add memory to the machine so that more reads are served from the page cache and the disk is asked fewer questions. They try the memory option first because it is cheapest, then grow the disk modestly, and the throttling disappears. The lesson is to measure, change one thing at a time, and measure again.

Block size and access patterns

The size of each request matters as much as the number of requests. Imagine moving a sandy beach. You can carry it grain by grain, which is slow and tiring, or in big bucketfuls, which is fast. Small requests, such as four kilobytes at a time, are limited mostly by operations per second. Large requests, such as one megabyte at a time, are limited mostly by throughput. A workload with a random pattern jumps around the disk, and a sequential workload reads or writes in order. Hard-drive-based Standard disks do far better with sequential patterns, while solid-state types handle random patterns well.

Benchmarking with care

Always benchmark on a test copy, never on a live production disk, because a heavy test can fill queues and slow real users. Choose a benchmarking tool that lets you set the request size, the read and write mix and the number of requests in flight. Run each test long enough to move past short bursts, and record the results next to the machine type and disk size so you can compare later. Repeat the test after every change. A single run is an anecdote, and three runs are a measurement.

Where your disk lives decides what kind of disaster it can survive.

A zonal Persistent Disk keeps all its copies inside one zone. If that zone has a serious problem, such as a power failure or a network fault, the disk and the machines attached to it may be unavailable until the zone recovers. For many workloads this is acceptable, especially when you also keep good backups.

A regional Persistent Disk keeps copies in two zones of the same region and writes to both at the same time. This is called synchronous replication, which means a write is confirmed only after both zones have stored it. If one zone fails, the data is still in the other zone, and you can start a replacement machine there and attach the same disk.

flowchart TD
  subgraph ZA["Zone A"]
    VMA["Primary VM"]
    RA[("Regional PD Replica A")]
  end
  subgraph ZB["Zone B"]
    VMB["Standby VM"]
    RB[("Regional PD Replica B")]
  end
  VMA -->|"Reads and writes"| RA
  RA |"Synchronous replication"| RB
  VMB -.->|"Attaches after failover"| RB
  ZA -. "Zone A fails" .-> VMB
    

How a failover works

The price of regional protection

Regional disks cost more, since you pay for storage in two zones, and every write must wait for both zones, so latency for writes is slightly higher than for a zonal disk. Regional disks also support fewer disk types than zonal ones, so verify your choice against the current documentation. For most teams, the best approach is to use regional disks only for data where short downtime is truly costly, and rely on snapshots and good design everywhere else.

When to choose which

Split-brain: the danger to avoid

During a failover, it is vital that only one machine writes to the disk at any moment. If the old machine in the failed zone is merely unreachable and not truly stopped, and the new machine also begins to write, two writers could damage the data. This dangerous situation is called split-brain. Force-attach is powerful because it breaks the old attachment, so use it with clear rules: confirm that the old machine is stopped or fenced off before the new machine starts writing. Good automation handles this step carefully, and good runbooks make the human steps explicit.

The lifecycle of a data disk, from an empty shell to a working part of your system. No commands are needed to understand the steps.

Using a new data disk always follows the same path. Knowing the order helps you avoid the classic mistake of attaching a disk and then wondering why the machine cannot see any files.

Two classic traps

Detaching safely

Before you detach a disk, stop the application using it and unmount the file system. This makes sure all buffered data is written out. Detaching a disk that is busy is like pulling a USB drive out while files are still copying, and it can leave the file system in a damaged state that needs repair.

Choosing a file system

The file system you create on a disk affects speed, safety and tools. On Linux, ext4 is a mature, widely supported choice that works well for most workloads. XFS is popular for very large files and heavy parallel work, and many database vendors recommend it. On Windows, NTFS is the standard. Pick the file system your application vendor recommends, and use the same choice across similar machines so that your team learns one set of habits instead of many.

Some applications can also use a raw disk directly, with no file system at all, but this is rare and specialised. For nearly every beginner, a standard file system is the right starting point. Remember that the file system, not the cloud, decides what happens to your files after a crash, so keep it healthy with updates and occasional checks.

Mount options worth knowing

When you mount a disk, you can add options that change its behaviour. A common option is to skip updating access times on every read, which reduces needless writes. Another is the optional-mount flag mentioned earlier, which prevents a missing disk from blocking startup. Apply options deliberately and document them in your runbook, because a surprising option discovered during an outage is an unpleasant way to learn.

One of the greatest gifts of cloud storage is that you can grow a disk without stopping your system.

A Persistent Disk can be made larger while it is attached and in use. You increase the size in the control plane, and the new space appears to the virtual machine. However, the file system does not know about the extra space until you tell it to grow. So resizing has two stages: first the disk, then the file system on top of it.

Important rules about resizing

• Growing is easy; shrinking is not possible in place. You cannot reduce the size of an existing disk. To get a smaller disk, create a new smaller one and copy the data across.
• Take a snapshot first. Resizing is safe by design, but a fresh snapshot costs little and protects you from human error in the file system step.
• Resizing also raises speed. Since performance is tied to size on most types, a bigger disk may also become faster, which can be a useful side effect.
• Plan growth steps. Grow in sensible chunks and set alerts before the disk is nearly full, because a completely full file system causes application failures.

Changing the disk type

Sometimes you discover that a disk is the wrong type. Changing the type of an existing disk is generally done by taking a snapshot and creating a new disk of the new type from it, then swapping disks. Some newer options allow more direct changes, so check the current documentation. Plan a short maintenance window for the swap, and test the new disk before removing the old one.

Routine health habits

A disk keeps your data safe from hardware failure. Snapshots keep it safe from everything else.

A snapshot is a saved copy of a disk’s contents at one moment in time. Snapshots are stored separately from the disk, in Google’s durable object storage, so they survive even if the disk is deleted. They are the main tool for backups, for recovery after mistakes, and for copying a disk to another zone or another project.

Incremental by design

Snapshots are incremental. The first snapshot of a disk copies all the used data. Every later snapshot stores only the blocks that changed since the previous one. This makes frequent snapshots fast and keeps the cost low. You can still restore a full disk from any single snapshot, because the system keeps track of how the pieces fit together. Deleting an older snapshot does not break newer ones, since the service preserves any data that later snapshots still need.

flowchart LR
  D["Live Disk"] -->|"First snapshot, all used blocks"| S1["Snapshot 1"]
  D -->|"Changed blocks only"| S2["Snapshot 2"]
  D -->|"Changed blocks only"| S3["Snapshot 3"]
  S3 --> N["New disk in any zone"]
  S2 --> N2["Restore point after a mistake"]
  S1 --> IMG["Custom image for new VMs"]
    

Snapshot schedules

You do not need to remember to take snapshots. A snapshot schedule is a rule that takes snapshots automatically, for example every six hours, and deletes old ones after a retention period, for example thirty days. Attach the schedule to a disk, and the system does the rest. A good schedule balances two ideas: how much recent data you can afford to lose, and how much you are willing to pay for stored snapshots.

Consistency: crash-consistent or application-consistent

A snapshot taken while the application is busy captures the disk exactly as it was at that instant. This is called a crash-consistent snapshot, because restoring it looks like the machine lost power at that moment. Well-built databases recover from this automatically. For stronger guarantees, take an application-consistent snapshot by briefly pausing writes or flushing the database before the snapshot begins. On Windows, a built-in service can help the applications cooperate. For critical databases, ask your database vendor which method they recommend.

Snapshots, images and machine images

Where snapshots are stored

When you create a snapshot, you choose a storage location. A multi-regional location keeps copies across a wide area, which protects against the loss of a whole region. A regional location keeps copies in one region, usually at lower cost and closer to your disks. Pick the location by asking two questions: how bad would it be if an entire region were lost, and where will I most likely restore this data? Regulated data may also be required to stay inside a country or a legal area, so check your rules before choosing.

Snapshot costs in plain words

You pay for the storage that your snapshots occupy. Because they are incremental, a chain of snapshots usually costs far less than the same number of full copies. Costs still grow when your data changes a lot, because every changed block must be stored. A database that rewrites large parts of its files every night produces bigger snapshots than a file server that rarely changes. If snapshot costs surprise you, check how much data changes between snapshots, how long you keep them and whether temporary files or caches are sitting on a disk that you snapshot unnecessarily.

A normal disk belongs to one machine at a time. Here is what to do when many machines need the same data.

By default, a Persistent Disk is attached to one virtual machine in read-write mode. This is the safest arrangement, because a normal file system assumes only one computer is changing it. If two machines wrote to the same ordinary file system at once, they would overwrite each other’s changes and quickly corrupt it.

Your options for sharing

Which one should you choose?

If the data never changes while machines read it, use read-only attach. If many machines need a normal shared folder that changes, use Filestore. If you serve large files to users or applications, use Cloud Storage. Reserve multi-writer mode for specialised software that explicitly supports it. Beginners who try to share a regular disk by attaching it read-write to two machines usually end up with damaged data.

Containers are temporary by nature. Persistent Disk gives them a memory that outlives them.

A container is a small, packaged program that runs on a shared machine. When a container restarts, everything written inside it is normally lost. That is perfect for stateless web servers, but terrible for databases and message queues. Kubernetes is the system that runs and manages many containers, and Google Kubernetes Engine, or GKE, is Google’s managed version of it. Kubernetes solves the memory problem with volumes, and on Google Cloud those volumes are very often Persistent Disks.

The three words to learn

How it behaves in practice

When a pod, which is one running unit of your application, asks for storage, the Google storage driver creates a disk in a zone where the pod can run and attaches it to the machine hosting the pod. If the pod is rescheduled to another machine in the same zone, the disk follows it. Because a normal disk belongs to a single zone, a pod that uses it must run in that zone. This is why zone planning matters for stateful applications.

Regional disks for stateful workloads

For important stateful applications, a StorageClass can request regional disks. This lets the pod move to the other zone after a failure and still find its data. It costs more but gives much better recovery for databases that run inside the cluster. Many teams combine regional disks with the database’s own replication for an extra layer of safety.

Google protects the hardware. You decide who may touch the data and who holds the keys.

Cloud security follows a shared responsibility model. Google secures the data centres, the physical drives and the storage service. You are responsible for who can create, attach, copy and delete disks, for the keys you choose to use, and for the data inside the file system.

Encryption at rest and in transit

Data on Persistent Disk is encrypted at rest by default, which means the stored bytes are scrambled so that anyone who obtained the physical drive could not read them. You do not need to switch this on, and it does not require extra effort in your applications. Data travelling between your virtual machine and the disk is also protected within Google’s infrastructure.

Choosing who controls the keys

Controlling access

Identity and Access Management, called IAM, decides which people and programs can do what. A role is a bundle of permissions. Following the principle of least privilege, give each person only what they need. A developer may need to attach disks but not delete them. An automation account may need to take snapshots but not read them. Snapshots can contain the same sensitive data as the disk, so protect them with the same care.

Security habits

• Protect snapshots. Restrict who can create disks from them, and who can copy them to other projects.
• Use dedicated service accounts. Each application gets its own robot identity with narrow permissions.
• Enable audit logs. Record who created, deleted or shared disks so you can investigate incidents.
• Wipe responsibly. Deleting a disk makes its data unavailable, and Google handles the destruction of the underlying storage. For regulated data, follow your own policy and consider key destruction as an additional control.
• Separate environments. Keep test and production disks in different projects so mistakes in one do not touch the other.

A slow disk rarely announces itself. You must watch the right numbers to notice.

Google Cloud collects disk metrics, which are measured numbers over time, and shows them in Cloud Monitoring. The most useful ones tell you how many read and write operations occur, how many bytes move, and how much of the allowed capacity you are using. Operating system tools inside the machine add details such as how long each request waits and how full the file system is.

The signals worth watching

Alerts that help

An alert is a message that wakes a person, so it must be worth waking up for. Good disk alerts include file system usage above eighty percent, sustained throttling, and latency far above normal. Weak alerts, such as a brief spike in operations, create noise and teach people to ignore alarms. Link every alert to a short guide that explains what to check first and how to grow the disk or move to a faster type.

Audit and change history

Cloud Audit Logs record administrative actions such as creating, resizing, attaching, snapshotting and deleting disks. When something disappears, the audit log is the first place to look to learn who did what and when. Make sure these logs are kept long enough for your compliance needs.

Reading the signals together

A single metric rarely tells the whole story, so learn to read them as a team. The table below shows common combinations and what they usually mean.

Tools inside the machine

Operating system tools show details that cloud metrics cannot. On Linux, standard utilities can show per-device utilisation, average wait time and queue length every few seconds. On Windows, the built-in performance monitor offers similar counters. Learn one such tool well, and use it side by side with the cloud dashboard. When the two agree, you can trust your diagnosis, and when they disagree, you have found something interesting.

Plan for the bad day before it arrives. Here is what can go wrong and what each protection really covers.

Durability is the likelihood that your data survives and can be read later. Persistent Disk is designed for very high durability, because every write is stored redundantly on separate hardware. But durability against hardware loss is only one kind of safety. Different failures need different defences.

Recovery goals

Two numbers shape every recovery plan. The recovery point objective, or RPO, is how much recent data you can afford to lose. The recovery time objective, or RTO, is how long you can afford to be down. If your RPO is one hour, you need snapshots or replication at least hourly. If your RTO is fifteen minutes, a restore that takes half a day is not good enough, however carefully it was written.

A practical recovery ladder

Live migration and maintenance

Google regularly maintains the physical machines that run your virtual machines. For most machine types, a feature called live migration moves the running machine to other hardware without stopping it, and the disk connection continues without interruption. Because the disk lives separately, this does not affect your data. Some specialised machine types cannot live migrate and may restart, so design applications to start cleanly after a restart.

Disks are quiet spenders. They bill every hour, whether anyone is using them or not.

Persistent Disk is billed mainly by provisioned capacity. This means you pay for the gigabytes you created, not for the gigabytes you filled. A 500 gigabyte disk that holds 20 gigabytes of data costs the same as one that is full. Prices depend on the type, with Standard cheapest and the SSD types more expensive, and regional disks cost more because they store data in two zones. Extreme disks also charge for the operations you provision. Because prices change and vary by region, always check the official pricing page and use the pricing calculator before planning a budget.

What drives the bill up

How to keep it under control

• Find and review orphaned disks monthly. If nobody owns a disk, snapshot it and delete it.
• Label everything. Add labels for owner, application and environment so cost reports show who spends what.
• Match type to purpose. Use Standard for cold bulk data, Balanced for general work, and faster types only where measurements justify them.
• Set snapshot retention. Keep dense recent snapshots and sparse older ones.
• Set budget alerts. A simple alert at eighty percent of the monthly plan prevents unpleasant surprises.

A thought experiment: two storage plans

Consider a company that keeps 10 terabytes of old compliance records. Nobody reads them more than a few times per year. If the records sit on an SSD disk, the company pays a premium price every month for speed that nobody uses. Moving them to a Standard disk lowers the bill considerably. Moving them further to Cloud Storage may lower it more, because object storage is built for exactly this kind of cold data. The right answer depends on how the records are accessed, and the habit to build is to ask that question for every large disk.

Now consider a busy order database of only 300 gigabytes. Its disk is small, but every second matters, so it sits on a fast SSD disk with a regional option for safety and a snapshot every few hours. Its disk bill per gigabyte is much higher than that of the records archive, and rightly so, because each gigabyte earns money. Spending should follow value, not size.

Practical clean-up routine

An honest look at what you gain and what you give up.

The big trade-offs in plain words

Durability against speed. Local SSD is faster because it is inside the host, but it gives up the safety of network storage. Persistent Disk accepts a small delay in exchange for data that outlives its machine.

Protection against price. Regional disks, frequent snapshots and cross-region copies all cost money. Spending should follow the value of the data. A cache can live on a cheap disk with no backups. A customer database deserves layers.

Simplicity against flexibility. Persistent Disk is easy to understand, but its speed rules tie performance to size. Hyperdisk gives more freedom to tune, and with it, more settings to understand.

Google Cloud offers several storage products. Knowing the neighbours helps you pick the right home for each kind of data.

flowchart TD
  Q1{"Is the data only scratch or cache that can be rebuilt?"}
  Q1 -- "Yes" --> LS["Local SSD"]
  Q1 -- "No" --> Q2{"Do many machines need to write to the same files?"}
  Q2 -- "Yes" --> FS["Filestore"]
  Q2 -- "No" --> Q3{"Are they large files or media served over the web?"}
  Q3 -- "Yes" --> GCS["Cloud Storage"]
  Q3 -- "No" --> Q4{"Need to tune IOPS and throughput on their own?"}
  Q4 -- "Yes" --> HD["Hyperdisk"]
  Q4 -- "No" --> PD["Persistent Disk"]
    

Comparing the options

The most common beginner mistake is using a disk as a place to store huge media libraries that many services download. That job fits Cloud Storage far better, since it scales without limit, costs less per gigabyte and is reachable from anywhere. Keep disks for data that needs the behaviour of a real drive, such as database files and operating systems.

A pattern is a proven recipe for a common problem. These five work especially well with disks.

The write-ahead log pattern

Many databases write every change first to a sequential log and later apply it to their main data files. Sequential writes are fast even on modest disks. Putting the log on its own fast disk can sharply improve commit speed, while the large data files sit on a cheaper, larger disk. This is a very common arrangement for relational databases on Compute Engine.

The ephemeral compute pattern

Treat virtual machines as disposable and disks as precious. When you need an upgrade, build a new machine from an image, attach the existing data disk, and delete the old machine. Because the data never moved, the upgrade is quick and the rollback is simple: reattach the disk to the old machine design.

An anti-pattern is a habit that looks sensible at first and causes pain later.

A checklist to read before your first production launch.

Best practices

Common mistakes

How teams typically use Persistent Disk in production.

Specific company architectures change over time and are rarely published in detail, so the following examples describe common patterns seen across the industry rather than any one named company. They show how the ideas in this guide combine in practice.

Disks are tied to a zone, but your needs are not. Here is how data travels.

Because a zonal disk lives in one zone, moving it to another zone, another region or another project always involves a copy. The cleanest tool for this is the snapshot, since snapshots are not tied to a zone and can create disks anywhere.

Moving between zones, regions or projects

Changing disk families

Newer machine families may require or prefer Hyperdisk. When you upgrade a machine, check its supported disk types first. Often the move follows the same path: snapshot the old disk, create a new disk of the new family from it, and attach it to the new machine. Test performance carefully, because the speed rules of the new family can differ from the old rules.

Bringing data from outside Google Cloud

To bring an on-premises server’s disks to the cloud, you can import a disk image through Google’s migration tools, or you can create a fresh disk and copy files over a network link. For very large data, offline transfer devices may beat the internet. Plan the cut-over carefully: copy the bulk data early, then run a short final sync while the application is paused.

Keeping current

Disk types, limits and machine support change as Google updates its products. Make it a habit to read the release notes a few times a year, review the supported disk list for the machine types you use, and re-check your performance assumptions when you resize or change machines.

Quick answers to the questions beginners ask most often.

If you remember only one page of this guide, make it this one.

Persistent Disk is Google Cloud’s durable network block storage. It keeps your data safe from machine stops and hardware failures, grows while running, and plugs easily into Compute Engine and Kubernetes. Speed depends on the disk type, its size and the machine it is attached to. Safety depends on snapshots, access control and practised recovery, not on replication alone. Cost follows provisioned size, so right-sizing, correct types and regular clean-ups matter.