Before the details, let us understand the problem that Filestore solves, using a simple story.

The problem: many machines, one set of files

A normal computer disk belongs to one computer. If you save a file on it, only that computer can open it directly. That is fine for a laptop. But modern systems often run on many machines at once. A website might run on twenty servers, and all twenty must show the same uploaded pictures. A video studio might use five hundred machines to draw one film, and every machine needs the same models and textures. A scientific lab might run a thousand jobs that all read the same data.

If each machine kept its own copy of the files, the copies would drift apart. One server would have the new picture, and nineteen would not. Copying files around by hand is slow and full of mistakes. What these systems need is one single, shared place for files that every machine can reach.

The old way: running your own file server

Before managed services, teams built their own file servers. They set up a machine, attached disks, installed software to share folders over the network, planned backups, watched for failures, applied updates and hoped nothing broke at night. If the file server failed, every machine that depended on it stopped working. Running a file server well is real work, and it is easy to get wrong.

The Filestore way: a managed shared folder

Filestore removes that work. It is a managed service, which means Google takes care of the hardware, the operating system, the software that shares the files, the repairs and the upgrades. It uses a very common sharing method called NFS, which stands for Network File System. NFS has been used for decades, and almost every Linux program already knows how to talk to it. That means your existing software usually works with Filestore without being rewritten.

A short history

Google Cloud introduced Filestore in the late 2010s, at first with simple service levels aimed at general file sharing. Over time Google added faster and bigger levels for heavy workloads, and then levels designed for high availability, which survive the loss of a data center building. The product has grown from a basic shared folder into a family of options for different needs.

Where Filestore sits among Google Cloud storage options

Google Cloud offers several kinds of storage. Each is best at a different job.

The word “storage” hides three very different ideas. Understanding the difference makes every later chapter easier.

Block storage: the raw disk

Block storage is the plainest kind. The storage is cut into equal-sized pieces called blocks, and the computer that owns the disk decides how to arrange files on them. It looks to the computer like an empty hard drive. Persistent Disk is block storage. It is fast and flexible, but it is normally attached to one machine at a time. The computer using it must run the software that organizes files on it.

File storage: folders and files

File storage adds the organization for you. It gives you folders, file names, permissions and the usual actions: open, read, write, rename, delete, lock. Many machines can connect to the same file storage at once through the network, and the service keeps them all consistent. Filestore is file storage.

Object storage: a giant bucket of items

Object storage keeps each item as a whole object with a name and some descriptive information. You usually reach it through web requests rather than as a mounted folder. It is extremely scalable and cheap, but it does not behave exactly like a normal disk. For example, you generally replace a whole object instead of changing a few bytes in the middle. Cloud Storage is object storage.

Why not just use Cloud Storage for everything?

Cloud Storage is wonderful, but many older programs expect a normal folder with fast small reads and writes, file locking and instant visibility of changes. Tools exist that make a bucket look like a folder, but the behavior and speed are different from a true file system. When an application depends on classic file behavior, Filestore is usually a closer fit.

Why not just share one Persistent Disk?

A Persistent Disk can be attached to several machines only in limited ways, mostly in read-only mode for extra machines. It does not coordinate many writers. Filestore is built for exactly that: many readers and writers, with a server that keeps order.

Filestore has a small vocabulary. Learn these words once, and the rest of the guide will feel familiar.

Instance

A Filestore instance is one managed file server that you create. It is not a virtual machine you log in to. It is a service object that Google runs for you. Each instance has a name, a location, a service level, a size and a network.

File share

A file share is the actual folder tree that clients mount. Inside an instance, you create a share with a name, such as “media” or “uploads”. Machines connect to a share, not to the instance as a whole. Some newer levels allow several shares inside a single instance.

Capacity

Capacity is the amount of space you ask for. Filestore bills you for the capacity you provision, whether or not you fill it. That is different from object storage, where you pay for what you store.

Service tier

A tier, also called a service level, is the kind of Filestore you choose. Tiers differ in speed, size limits, availability and features. We study them in a later chapter.

Location: zone and region

Like other Google Cloud resources, a Filestore instance lives in a zone or, for some tiers, a region. A zone is one isolated group of data center resources. A region is a geographic area with several zones. Choosing a regional tier means your data is kept across more than one zone.

VPC network

A Virtual Private Cloud, or VPC, is your own private network inside Google Cloud. A Filestore instance gets a private address inside it. Filestore is meant to be reached privately, from machines on your network, not from the open internet.

NFS, mount and export

NFS is the language machines use to share files over a network. The machine that offers files is the server. The machines that use them are clients. To mount a share means to attach the remote folder so that it appears at a chosen path on the client, for example a path called /mnt/media. After mounting, programs read and write there as if the files were local. The server decides which clients may connect and what they may do, which is often called the export or access rules.

Snapshot and backup

A snapshot is a quick point-in-time picture of a share that stays close to the live data. A backup is a separate, protected copy of the share kept in another place. Both help you recover from mistakes. We cover them in the data protection chapter.

Now let us zoom out and see how Filestore connects to the machines that use it.

A typical setup has four groups of parts. First, the clients: virtual machines, containers or other services that need the shared files. Second, the network: your VPC, with firewall rules and a private address for the Filestore instance. Third, the Filestore service itself: the managed file servers and the storage behind them. Fourth, the supporting services: identity and access controls, monitoring, logging and backup storage.

flowchart TD
  subgraph VPC["Your VPC Network"]
    subgraph COMP["Client Machines"]
      VM1["Compute Engine VM 1"]
      VM2["Compute Engine VM 2"]
      GKE["GKE Pods using CSI driver"]
      RUN["Cloud Run service with NFS mount"]
    end
    FW["VPC Firewall Rules"]
  end
  VM1 -->|"NFS requests"| FW
  VM2 -->|"NFS requests"| FW
  GKE -->|"NFS requests"| FW
  RUN -->|"NFS requests"| FW
  FW --> EP["Filestore Private Endpoint"]
  subgraph FS["Filestore Service Managed by Google"]
    EP --> SRV["NFS Server Layer"]
    SRV --> STO["Distributed Storage Layer"]
  end
  STO --> SNAP["Snapshots"]
  STO --> BKP["Backups in Regional Storage"]
  IAM["IAM Permissions"] -.-> FS
  MON["Cloud Monitoring and Logging"] -.-> FS

Walking through the picture

On the top are the clients. Here we show two Compute Engine virtual machines, a group of Kubernetes pods and a Cloud Run service. All of them mount the same share. Each client sends NFS requests, which are small messages like “read this part of this file” or “write these bytes to that file”.

The requests travel inside your VPC network. The firewall rules act as guards, allowing NFS traffic only from the places you approve. The traffic reaches the private endpoint of the Filestore instance. This is a private address, so the service is not open to the whole internet.

Inside the Filestore service, an NFS server layer receives the requests, checks permissions, and organizes the files. Behind it is a distributed storage layer where the data is kept on many disks, so a single disk failure does not lose your files. You never see these internal machines, and you never patch them.

Supporting parts surround the service. Snapshots and backups protect against mistakes. IAM, which means Identity and Access Management, controls who can create, change or delete instances. Monitoring and logging collect numbers and messages about how the service is doing.

Why this design works

The separation of jobs is the secret. Clients only need to speak NFS. The service hides the servers and the disks, so Google can replace broken parts, add faster hardware and move data around without your programs noticing. And because the endpoint is private and managed, you avoid the single lonely file server that someone has to babysit.

This is the part many tutorials skip. Knowing it explains why Filestore behaves the way it does.

Clients and servers talking in small requests

NFS is a conversation. The client does not download an entire file when you open it. Instead, it sends many small requests: find this file name, tell me its size, read the bytes from this position to that position, write these bytes here. The server answers each one. This lets programs work with very large files while touching only the pieces they need.

Versions of NFS

NFS has several versions. NFS version 3 is simple, widely supported and “stateless” in its core design, which means the server does not need to remember much about each client between requests. NFS version 4.1 is newer, keeps more information about open files and locks, and adds features such as better security options and the ability to talk to servers in parallel. Different Filestore tiers support different versions, so check which one your application needs.

Mounting: the first step

When a client mounts a share, it contacts the server at its private address, asks for the share by name, and receives a handle, which is a small token that refers to the root folder. From then on, every operation uses handles. The mount command also carries mount options, such as how large each read or write may be and how the client should behave if the server is slow to answer.

Reading and writing

When a program reads a file, the client’s operating system turns the request into NFS read messages. The Filestore server fetches the data from its storage layer and sends it back. For writes, the client sends data to the server. The server can confirm in two styles. A stable write is confirmed only after the data is safely stored. An unstable write is confirmed sooner, and the client later sends a commit message that asks the server to make sure everything is safely stored. This trick makes many writes faster while still giving a safety point.

Client-side caching

To go faster, clients keep copies of recently read data and file details in their own memory. This is caching. It makes repeated reads very quick, since no network trip is needed. The trade-off is that a client’s copy might be slightly out of date if another client has just changed the file. NFS clients check back with the server from time to time, controlled by timers in the mount options. This is why two machines may briefly see slightly different views right after a change, and why programs that need strict instant agreement must use locking or special mount settings.

Locking

When two programs might change the same file, they need a way to take turns. A lock says, “I am using this file, please wait.” NFS supports locking, and Filestore supports it. Good applications use locks for shared files, rather than hoping that two writers will never collide.

Permissions and identities

Files have owners and permissions. In NFS version 3, the client simply tells the server which user number and group number are asking, and the server believes it, as long as the client’s address is allowed. This means the server trusts the client machines, so it is important to control which machines can connect. The server can also apply root squashing, which treats the all-powerful “root” user from a client as an ordinary user, so a compromised client cannot freely take over every file.

Behind the scenes: the storage layer

Below the NFS layer, Filestore stores data on many disks managed by Google, with redundancy so that single failures do not lose data. The exact design depends on the tier. Some tiers keep data inside one zone. Higher-availability tiers keep it across zones. As a user, you do not manage any of this, but it explains why some tiers are more expensive: they do more copying to protect you.

Filestore comes in several tiers. Picking the right one is the single most important decision you will make.

Why tiers exist

Different jobs need different things. A small team sharing office documents needs a modest, low-cost folder. A genomics lab needs enormous capacity and fast reads. A bank’s core application needs a folder that keeps working even if a whole data center building loses power. One product cannot be perfect for all three, so Google offers tiers.

The main tiers

Comparing the tiers on the things that matter

Capacity and size limits

Each tier has a minimum and a maximum size. Entry-level tiers start in the low terabytes. Higher tiers allow very large instances, into the tens or even over a hundred terabytes, and some allow resizing in small steps. A terabyte is about one thousand gigabytes, a unit that is easy to picture as roughly a few hundred thousand photos. Do not memorize numbers. Look them up when you plan.

NFS versions by tier

Basic tiers use NFS version 3. Higher tiers add support for NFS version 4.1. If your application needs stronger locking behavior or other version 4 features, choose a tier that offers it.

How to choose

From creation to deletion, every instance follows a story. Knowing it avoids surprises.

Creating an instance

You create an instance through the console, the command line tool or an automated tool such as Terraform. You choose a name, a location, a tier, a capacity, a VPC network, and the name of the first file share. You may also set access rules, which say which client addresses may connect and with which rights.

Mounting from a client

sequenceDiagram
  participant A as Application
  participant K as Client OS NFS Driver
  participant F as Filestore Endpoint
  participant S as Storage Layer
  A->>K: Open file for reading
  K->>F: Look up file name
  F-->>K: File handle and size
  K->>F: Read bytes from position
  F->>S: Fetch data blocks
  S-->>F: Data blocks
  F-->>K: Data returned
  K-->>A: Data delivered
  A->>K: Write changes
  K->>F: Write request
  F->>S: Store data safely
  S-->>F: Stored
  F-->>K: Write confirmed
  K-->>A: Write complete

What the picture shows

The application does not know it is using a network. It simply opens, reads and writes. The client operating system’s NFS driver translates those actions into messages. The Filestore endpoint finds the file, asks the storage layer for the data, and sends it back. For a write, the data is stored before the success message returns, if the write is a stable one.

Data flow at runtime

Once running, data moves in several directions. File reads and writes go from clients to the service. Snapshots and backups move data inside Google’s systems, without using your clients’ bandwidth. Monitoring numbers flow to Cloud Monitoring. Administrative actions, such as creating or resizing instances, appear in audit logs.

Locations of instances and clients

For best speed, place clients in the same zone as a single-zone instance, or in the same region as a regional instance. Crossing zones or regions adds delay for every request, and may add network charges. Latency is the delay in each round trip, and in NFS it is paid again and again, so it matters a great deal.

Filestore is private by design. Understanding how machines reach it, and who is allowed in, keeps your data safe and your mounts working.

A private address in your VPC

Each Filestore instance receives a private IP address inside a network. An IP address is the number that identifies a machine on a network. Your clients use this private address to mount the share. The address is not reachable from the public internet.

How the connection is made

Filestore runs in a network owned by Google, and your clients run in your own VPC. These two must be joined. For many tiers this is done with private services access, which creates a private link, called peering, between your network and Google’s service network. You reserve a block of private addresses for it. Newer options use Private Service Connect, which exposes the service as a single endpoint inside your own network and avoids reserving a big range. Which method is available depends on the tier, so check the current documentation.

flowchart LR
  subgraph YOURS["Your VPC Network"]
    C1["Client VM in Zone A"]
    C2["Client VM in Zone B"]
    GK["GKE Nodes"]
    FW["Firewall Rules allow NFS from approved clients"]
  end
  subgraph ONP["On-premises Network"]
    OFF["Office or Data Center Servers"]
  end
  subgraph GOOG["Google Managed Service Network"]
    FSI["Filestore Instance"]
  end
  C1 --> FW
  C2 --> FW
  GK --> FW
  FW -->|"Private connection"| FSI
  OFF -->|"Cloud VPN or Interconnect"| YOURS
  OFF -.->|"via your VPC"| FSI

Firewall rules

A firewall rule decides which network traffic is allowed. For NFS to work, the rules must allow traffic between your clients and the Filestore address. Allow only the client machines that need access, not your whole network. Many teams use network tags or service accounts to target the right machines.

Access control on the file share

Besides the firewall, Filestore lets you define access rules on a share. A rule names an address or a range of addresses and states what those clients may do, for example read-only or read-write. It also says whether root squash applies. If no rules are set, all clients that can reach the instance are allowed by default, so setting explicit rules is a good habit for sensitive data.

Two layers: IAM and NFS permissions

Two different permission systems apply. IAM decides who can manage the Filestore instance itself, such as creating, resizing or deleting it. NFS permissions decide who can read and write files inside the share. Giving someone IAM rights does not give them file access, and the reverse is also true.

Reaching Filestore from outside Google Cloud

Servers in your own office or data center can mount a Filestore share if they have private connectivity to your VPC, using Cloud VPN, an encrypted tunnel over the internet, or Cloud Interconnect, a dedicated private line. Routing and firewall rules must allow the traffic. Expect extra delay compared with machines inside Google Cloud, so test performance before depending on it.

Planning address ranges

Address ranges must not overlap between the networks that are joined. If your office network and your cloud network both use the same private range, traffic cannot be routed cleanly. Plan ranges before you start, as changing them later is painful.

Speed is where file storage choices become real. Let us learn what to measure and how to improve it.

The three measures of speed

• Throughput is how much data moves per second, such as megabytes per second. It matters most for big files, like videos and large data sets.
• IOPS stands for input and output operations per second. It counts how many separate small reads and writes can happen each second. It matters most for many small files and for databases.
• Latency is the time one request takes from start to finish. It matters most when programs wait on each answer before sending the next request.

Performance grows with capacity

In several tiers, the performance you get depends on the capacity you provision. A bigger instance is allowed more throughput and more IOPS. This surprises many beginners: sometimes you buy extra capacity not because you need the space, but because you need the speed that comes with it. Check the published performance tables for each tier and size.

Performance depends on the client too

The server is only half of the picture. The client machine’s size matters, since small VMs have lower network limits. The number of parallel requests matters, since a single reader cannot keep a fast server busy. The mount options matter, since they set the size of each read and write. And the application’s habits matter, since many tiny operations are slower than a few big ones.

Ways to improve performance

Scalability: growing in both directions

Filestore scales in two ways. First, scale up: you can increase the capacity of an instance, which raises its performance limits, often without taking it offline. Second, scale out: you can create several instances and spread different shares across them, so that no single instance is overloaded. Some higher tiers are built to serve very large numbers of clients at once.

Measuring before and after

Never tune by feeling. Use Cloud Monitoring to watch throughput, operations per second and latency on the instance. Use common benchmarking tools, run on clients, to measure the real speed of your workload before and after each change. Change one thing at a time, so you know what helped.

Understanding a slow share

Because you pay for the space you provision, managing capacity is about balancing safety and cost.

Provisioned, not used

Filestore bills for provisioned capacity. If you create a one-terabyte instance and store ten gigabytes, you still pay for a full terabyte. This is the opposite of object storage. So the first lesson is: do not create a large instance “just in case”. Start with what you need, and grow when needed.

Growing an instance

Increasing capacity is usually a simple operation that can happen while clients are using the share, though large changes may briefly affect speed. Each tier has a step size, which is the smallest amount you can add. Check it in the documentation. Because growing is easy, run with a comfortable margin but not a huge one.

Shrinking an instance

Shrinking is more limited. Some tiers allow reducing capacity down to the amount of data stored plus some margin. Others do not allow shrinking at all, in which case you must create a new, smaller instance, copy the data over and delete the old one. Plan for this: it is much easier to grow than to shrink.

Watching free space

A full file share is dangerous. Programs that cannot write may crash, lose data or fail in strange ways. Monitor used space and set alerts, for example at seventy and ninety percent of capacity. Alerts should reach a person who can act, and a runbook should say how to grow the instance or clean up files.

Finding what takes space

When space runs low, find the biggest users. Common culprits are old temporary files, logs that nobody rotates, forgotten test copies and many versions of the same output. Use standard tools from a client machine to list large folders. Set a rule for how long scratch data may stay, and delete it on a schedule.

A simple capacity plan

1. Measure how much data you have now and how fast it grows per month.
2. Set a target of keeping at least twenty to thirty percent free space.
3. Calculate when you will cross seventy percent, and schedule a resize before then.
4. Review the numbers every month. Compare the forecast with reality and adjust.
5. Move cold data, files nobody opens anymore, to cheaper object storage.

Tiering data to save money

Most data cools with age. Last month’s project files are busy, but last year’s are almost never opened. A smart habit is to keep hot data on Filestore and move cold data to Cloud Storage, where it costs much less per gigabyte. Some teams use scripts, or storage management tools, that move files older than a set age to a bucket and leave a note about where they went.

Files get deleted by mistake, overwritten by bugs and sometimes attacked. Data protection is how you get them back.

Why redundancy is not a backup

Filestore already stores your data with redundancy, which means extra copies inside Google’s systems, so a failed disk does not lose files. But redundancy copies mistakes too. If someone deletes a folder, the deletion is instantly applied to every copy. A backup is different: it is a separate, older copy that is not changed when the live data changes. Redundancy protects against hardware failure. Backups protect against human error, bad software and attacks.

Snapshots

A snapshot captures the state of a file share at one moment. It is created quickly, because it records the current layout and then tracks only later changes. Snapshots are stored with the instance and let you restore single files or folders, or revert a whole share to an earlier moment. Snapshots are offered on the Zonal, Regional and Enterprise tiers. They are ideal for quick “undo” needs, such as recovering a file deleted an hour ago.

Snapshots live with the instance. If the instance is deleted, its snapshots go with it. So snapshots alone are not enough for disaster protection.

Backups

A backup is a copy of a file share stored separately from the instance, in Google-managed storage, usually in a region of your choice. The first backup copies all the data. Later backups copy only what changed, which saves time and cost. A backup remains even if the instance is deleted, and you can restore it into a new instance. Backups can be taken on demand or on a schedule that you automate.

Replication

Some tiers support replication, which means continuously copying a share to another Filestore instance, often in another region. If the primary location suffers a disaster, you can promote the copy and carry on. Replication gives a much shorter recovery time than restoring from a backup, but it costs more because a second instance runs all the time.

flowchart TD
  APP["Applications on clients"] --> PRIM["Primary Filestore Instance Region 1"]
  PRIM -->|"point in time pictures"| SNAP["Snapshots with the instance"]
  PRIM -->|"scheduled copies"| BKP["Backups stored separately"]
  PRIM -.->|"continuous copy"| REPL["Replica Instance Region 2"]
  BKP -->|"restore"| NEW["New Instance after incident"]
  REPL -->|"promote in disaster"| PROM["Promoted Replica serves clients"]
  SNAP -->|"restore single file"| PRIM

Comparing the three

Recovery targets

Two numbers guide your design. RPO, the Recovery Point Objective, is how much recent data you can afford to lose, measured in time. RTO, the Recovery Time Objective, is how long you can afford to be down. Daily backups give an RPO of up to a day. Frequent snapshots give an RPO of minutes or hours for small mistakes. Replication gives an RPO of seconds or minutes for disasters. Choose the mix that matches your business needs.

A sensible protection plan

Protection from attacks

Modern attacks, such as ransomware, encrypt or delete files. A backup that attackers cannot reach is your best defense. Limit who can delete backups through IAM, keep backups in a separate project with tighter access, and keep some long-lived copies that nobody can change quickly.

A shared file server is a shared dependency. If it stops, everyone who depends on it stops. This chapter explains how to keep it available.

What availability means

Availability is the share of time a service works. It is often described in “nines”. Ninety-nine point nine percent allows under nine hours of downtime a year. Ninety-nine point ninety-nine percent allows under an hour. Higher availability costs more, because it needs more copies in more places. Reliability is the wider idea that the service gives correct answers quickly over a long time.

Single zone versus multi zone

Entry-level and performance tiers keep an instance in one zone. Google protects the data inside it against disk and server failures, but a major problem with the whole zone could make the instance unavailable until it is restored. Regional and Enterprise tiers spread data and serving capacity across zones in a region. If one zone fails, the service continues from the others, usually with only a short pause while clients reconnect. Google offers a written uptime promise, called an SLA, for its higher-availability tiers. Read the current SLA for exact numbers and conditions.

What happens during maintenance

Google updates the service from time to time. On higher-availability tiers, updates are designed to cause little or no interruption. On some tiers, a brief pause in access may occur during maintenance. Applications should be written to tolerate short pauses, by retrying instead of crashing.

Client behavior during a pause

NFS mounts have two styles. A hard mount makes the client keep retrying forever until the server answers. Programs wait, but nothing is lost. A soft mount gives up after a set number of tries and returns an error to the program, which can corrupt data if the program does not handle errors. For almost all workloads that write data, hard mounts are the safer choice. The trade-off is that programs can freeze while the server is unreachable.

Design habits for reliable file storage

Blast radius

The blast radius of a failure is how much it harms. If all your applications share one big instance, a problem in that instance harms them all. If you give each important application its own instance, a problem harms only one. Separate instances cost a little more in minimum sizes, but they limit the damage and make troubleshooting simpler.

Recovery from a zone failure

Shared storage holds shared secrets. Good security uses several layers, so that one mistake does not open the door.

The shared responsibility model

Google secures the data centers, the hardware, the managed servers and the storage system behind Filestore. You are responsible for who can reach the service, who can manage it, which machines may mount it, what permissions the files carry, and how your applications behave. Because Filestore is managed, your share of the work is smaller than for a file server you run yourself, but it is never zero.

Layer 1: network isolation

Filestore is reached through private addresses only. Keep it that way. Do not expose it to the internet through tricks such as forwarding traffic from a public machine. Use firewall rules that allow NFS only from the specific clients that need it. Place sensitive instances in separate projects or separate networks so that a problem in a test network cannot reach production files.

Layer 2: access rules on the share

Set explicit access rules for each share. Allow only needed address ranges, give read-only rights where writing is not needed, and turn on root squash so that a client’s all-powerful root user is treated as an ordinary user. Without root squash, someone who takes control of a single client machine could read or change every file.

Layer 3: IAM for management

IAM controls who may create, resize, back up or delete instances. Follow least privilege: give each person or program only the roles it needs. Separate the people who can delete backups from the people who run daily operations. Use audit logs to record who did what to the instance, so you can answer questions after an incident.

Layer 4: file permissions

Inside the share, normal Linux permissions apply. Plan owners, groups and permission bits carefully. NFS version 3 trusts the user and group numbers that clients send, so make sure these are managed consistently across machines. A directory service, such as a central login system, helps keep user numbers the same everywhere.

Encryption

Data is encrypted at rest in Google’s storage by default, which means it is scrambled on disk so a stolen disk would be unreadable. By default, Google manages the keys. Some tiers let you use customer-managed encryption keys through Cloud KMS, the Key Management Service, so that you control the keys and can disable them if needed. For data in transit, remember that NFS traffic inside your private network is not encrypted by default in the basic style. For highly sensitive data, check which tiers and versions offer protection on the wire, and consider extra network controls and policies that restrict who can see the network path.

Protecting backups

Treat backups as sensitive as the live data, since they contain the same files. Restrict who can restore them, because restoring creates a readable copy. Also restrict who can delete them, because deleting removes your safety net.

Organization-wide guardrails

Organization policies let a central team set rules for many projects at once, for example requiring encryption keys of a certain kind or limiting which regions may hold data. Rules enforced by the platform are stronger than rules written in a document that people may forget.

Filestore is only useful when something mounts it. Let us see how the common Google Cloud compute services connect.

Compute Engine virtual machines

The simplest case is a Linux virtual machine. You install the standard NFS client tools if they are not already there, create a folder for the mount point, and mount the share using the instance’s private address and share name. To keep the mount after a restart, you add an entry to the machine’s file system table, or you handle the mount in a startup script. Windows machines can also use NFS with the proper client feature, though Windows shares are more commonly served by other services.

Google Kubernetes Engine

Kubernetes is a system for running many containers across many machines. Google Kubernetes Engine, or GKE, is Google’s managed Kubernetes. Containers are temporary by nature, and their own disks vanish when they stop. Containers that need shared or lasting files can use Filestore through a CSI driver. CSI stands for Container Storage Interface, a standard way for Kubernetes to talk to storage systems. With the Filestore CSI driver enabled, you describe the storage you need, and Kubernetes asks Filestore to create and attach it.

Two concepts appear. A persistent volume claim, or PVC, is a request for storage made by an application. A storage class names the type of storage to give. Many pods can use the same claim at once if it is a shared, read-write-many type, which Filestore supports naturally.

Multishares for Kubernetes

Each Filestore instance has a minimum size, often in the terabyte range. Giving every small application its own instance would waste money. The Enterprise tier offers multishares, which lets the CSI driver carve many small shares out of one instance, with each share as small as a few gigabytes. Several small claims share the cost and the management of one instance, while each still has its own folder.

flowchart TD
  subgraph CLUSTER["GKE Cluster"]
    P1["Pod A - web"]
    P2["Pod B - web"]
    P3["Pod C - worker"]
    PVC1["Claim 1 - 10 GiB"]
    PVC2["Claim 2 - 50 GiB"]
    CSI["Filestore CSI Driver"]
  end
  P1 --> PVC1
  P2 --> PVC1
  P3 --> PVC2
  PVC1 --> CSI
  PVC2 --> CSI
  CSI -->|"creates shares"| INST["One Filestore Enterprise Instance"]
  INST --> SH1["Share for Claim 1"]
  INST --> SH2["Share for Claim 2"]

Cloud Run and other services

Cloud Run, Google’s service for running containers without managing servers, can mount an NFS share such as Filestore as a volume. This allows serverless services to read and write shared files, which was once hard to do. The service must be connected to your VPC network so that it can reach the private address. Other services, such as some batch and managed notebook products, can also work with Filestore through their network settings.

On-premises and hybrid clients

As covered in the networking chapter, servers outside Google Cloud can mount a share through a private connection. This is useful during migration and for hybrid workflows, where some people or systems remain on site.

Choosing a client

You cannot fix what you cannot see. Monitoring turns a mysterious slow share into a clear picture.

The three kinds of signals

Metrics are numbers over time, such as bytes read per second. Logs are written messages about events, such as someone creating a backup. Alerts are messages that tell a person something needs attention. Together they answer: Is something wrong? What went wrong? Who needs to act?

Metrics Filestore provides

Filestore sends numbers to Cloud Monitoring automatically. They typically include the capacity used and free, read and write throughput, the count of read and write operations, and in some tiers the delays of operations. Use these to build a dashboard for each important instance. Names and details can change, so check the current metric list in the console.

Metrics from clients

The server’s view is only half the story. Clients also keep useful numbers, such as how long NFS requests take from their side and how many retries happen. Install the Ops Agent on virtual machines to collect system metrics and logs. Tools on the client can report NFS statistics, which help you see whether a slowdown is the server, the network or the client itself.

Logs and audit trails

Administrative actions on instances, such as creation, resizing, backup creation and deletion, appear in Cloud Audit Logs. Search them to find out who changed something and when. These logs are your first stop after any unexpected change. Retain them long enough to meet your rules.

What to watch

Alerts that help, not annoy

Good alerts point to problems that matter and that a person can act on. Bad alerts fire constantly for small things, and people learn to ignore them. Alert on symptoms, such as space nearly full or latency too high for a sustained time, rather than every small blip. Attach a short runbook to each alert. A runbook is a written list of steps for fixing the problem.

Capacity and cost dashboards

Besides health, track trends in used space, growth rate and cost per instance. Share these with the owners of each project. When people see their own numbers, they clean up more willingly.

File storage costs more per gigabyte than object storage, so understanding the bill matters.

What you pay for

• Provisioned capacity, charged per gigabyte for each hour the instance exists, at a rate that depends on the tier and the location.
• Backups, charged for the amount of backup data stored, per month.
• Snapshots, which on some tiers use space that counts toward capacity or are charged as stored data.
• Replication, which means paying for a second instance and for the data sent to it.
• Network traffic, especially data that crosses zones or regions or leaves Google Cloud.

Prices change and differ by region, so always read the current pricing page and use the pricing calculator before you commit to a design.

Why the bill can surprise you

Ways to save money

1. Choose the lowest tier that meets the need. Do not buy availability or speed you do not need.
2. Right-size capacity. Keep a healthy margin, but avoid large unused space.
3. Move cold data to Cloud Storage. Keep only active files on Filestore.
4. Delete test and finished-project instances. Use labels and owners to find them.
5. Set backup retention rules. Keep backups as long as rules require, and no longer.
6. Use multishares for many small needs. Share one instance across small container workloads rather than creating many small instances.
7. Keep clients close. Put clients in the same zone or region to avoid network charges and speed up reads.
8. Set budgets and alerts so someone is told before costs grow too far.

Comparing with the alternatives

A pattern is a proven way to solve a common problem. An anti-pattern looks reasonable but causes pain later.

Patterns that work

Anti-patterns to avoid

This chapter gathers the habits of teams that run shared storage well, and the mistakes of those who learned the hard way.

Best practices: planning

• Choose the tier from your real needs for availability, speed and features, not from habit.
• Check size limits, step sizes and NFS version support for the tier before you commit.
• Place instances and clients in the same zone or region.
• Use separate projects and networks for development, testing and production.
• Define infrastructure as code, using a tool such as Terraform, so every instance is reviewed and repeatable.
• Label every instance with owner, project, environment and cost center.

Best practices: operations

• Automate mounts in images or startup scripts, so new machines attach to the share without manual work.
• Use hard mounts with sensible timeouts for writable data.
• Monitor free space, throughput, operations and latency, with alerts and runbooks.
• Schedule snapshots and backups, set retention rules and test restores regularly.
• Review capacity every month and resize before you are short of space.
• Clean scratch folders on a schedule and archive finished data to Cloud Storage.

Best practices: security

• Allow NFS only from named client ranges, using firewall rules and share access rules.
• Turn on root squash and use read-only access where writing is not needed.
• Apply least-privilege IAM and separate the power to delete backups from daily operations.
• Use customer-managed encryption keys when your rules require control over keys.
• Keep audit logs and review them.

Common mistakes

Let us look at the kinds of work that shared file storage carries every day. Companies seldom publish detailed architectures, so these examples describe typical patterns in each industry.

What these stories have in common

Every example shares the same habits. Many machines need one consistent view of the same files. The software expects normal folders. Capacity is rented only for as long as the work lasts. Cold data moves to cheaper storage. Tiers are chosen for speed and risk. Backups and monitoring are in place from the start. The details differ between industries, but the core design is the same.

Most teams do not start with an empty share. They have existing files that must be moved safely, and a long life of operations ahead.

Moving data in

Several tools can copy data into Filestore. For files on a machine you control, standard copy tools that work over NFS, such as those that copy only changes, are simple and reliable. For large amounts of data from other places, Google offers transfer services that move data from on-premises storage or from other clouds in a managed way, with checks that the copy is complete. For huge, one-time moves from offline systems, physical transfer devices may be an option.

A safe migration path

Things that surprise teams

• Many small files copy slowly. A million tiny files can take much longer than a few huge ones of the same total size. Run copies in parallel.
• User numbers must match. If user and group numbers differ between old and new systems, permissions look wrong. Plan how to map them.
• Special features may not carry over. Some old systems use extra attributes or access lists that a simple copy does not preserve.
• Locks and open files. Files that are open and changing during the copy may be copied in a half-finished state. Schedule the final sync when writers are paused.
• Network limits. The link between your site and the cloud sets the speed. Estimate transfer times before you promise a date.

Operating day to day

After the move, life becomes routine. Check the dashboards each morning. Review the capacity forecast each month. Confirm that backups completed. Test a restore each quarter. Review access rules when teams change. Review costs and delete what is no longer needed. Keep your runbooks current, because a runbook that describes last year’s system is worse than none.

Infrastructure as code

Write the definition of your instances, shares, access rules and backup schedules in code, using a tool such as Terraform or Google’s own deployment tools, and store it in version control. This gives you a record of every change, lets you review changes before they happen, and lets you rebuild the whole setup quickly in another project or region.

Short, direct answers to questions that beginners ask most often.

You have now seen Filestore from the outside and from the inside. Here is the whole story in one place.

Filestore gives many machines one shared, managed folder over NFS. Clients send small requests through your private network to a managed server layer, which stores data redundantly on Google’s storage. You choose a tier for speed, size and safety, provision capacity, set access rules, and protect data with snapshots, backups and replication. Google runs the hardware and the service, and you design the use of it.