Cloud / Google FileStore Interview questions

Filestore is Google Cloud's fully managed network file storage service. It exposes a shared file system over NFS, so many Compute Engine VMs, GKE pods and other clients can mount the same directory at the same time and use normal POSIX file operations on it.

Google handles provisioning, in-zone or in-region redundancy, patching and hardware failures. You pick a tier, a capacity and a VPC network, and you get back an IP address and a share name to mount.

It fits workloads that need a real file system rather than object storage: shared home directories, content management, build farms, media rendering and lift-and-shift apps that expect a mounted path.

Filestore currently has two primary tiers, Zonal and Regional, plus older tiers that still appear in docs, APIs and existing deployments: Enterprise, Basic HDD and Basic SSD.

Naming history matters in interviews: Zonal (10 TiB to 100 TiB) replaced High Scale SSD, Basic HDD replaced standard, and Basic SSD replaced premium.

Filestore supports NFSv3 and NFSv4.1. SMB is not supported.

The protocol is chosen when the instance is created and applies to all shares on that instance. Clients select it with the mount option vers=3 or vers=4.1.

In practice, NFSv3 is the safe default when you mix old and new clients, because it works on every tier. Move to NFSv4.1 when you want a single-port firewall rule or Kerberos, and test client kernel support first.

An instance is the Filestore resource you create: it carries the tier, capacity, location, VPC network and the IP address clients connect to. A file share is the named export on that instance, for example vol1, that clients actually mount.

Most instances expose a single share. Clients mount it as INSTANCE_IP:/SHARE_NAME:

sudo mount -o rw,intr 10.0.0.2:/vol1 /mnt/vol1

The exception is an Enterprise instance used with multishares for GKE, which can host many small shares (up to 80) inside one instance.

Filestore suits any workload that needs a shared POSIX file system with low latency and file locking.

• Content management and web serving: multiple web servers sharing uploads and assets.
• Shared development storage: home directories, build artifacts and CI caches.
• Media rendering and transcoding: render nodes reading and writing the same project tree.
• HPC and batch compute: especially the Zonal tier with high throughput.
• GKE stateful apps: ReadWriteMany volumes shared across pods.
• Enterprise apps and VMware: SAP-style workloads and NFS datastores for Google Cloud VMware Engine.

Enable the Filestore API, then run gcloud filestore instances create with a tier, a share definition and a network.

gcloud services enable file.googleapis.com

gcloud filestore instances create nfs-demo \
  --zone=us-central1-a \
  --tier=ZONAL \
  --file-share=name=vol1,capacity=1TB \
  --network=name=default

For a Regional instance you pass --region instead of --zone. Once the instance is READY, read its IP address:

gcloud filestore instances describe nfs-demo --zone=us-central1-a --format='value(networks[0].ipAddresses[0])'

Instance creation usually takes a few minutes. Poll with gcloud filestore operations list or describe the instance until its state is READY before you try to mount, and check your Filestore quota in that region if the create call is rejected.

Mounting is a standard NFS mount. Follow these steps:

1. Install the NFS client: sudo apt-get install -y nfs-common on Debian or Ubuntu, nfs-utils on RHEL-family images.
2. Create a mount point.
3. Mount IP:/share.
4. Add an /etc/fstab entry so it survives reboots.

sudo mkdir -p /mnt/vol1
sudo mount -o rw,intr 10.0.0.2:/vol1 /mnt/vol1

# /etc/fstab
10.0.0.2:/vol1 /mnt/vol1 nfs defaults,_netdev 0 0

The VM must be in the same VPC (or reach it over peering, VPN or Interconnect) and its IP must be allowed by the share's export options.

The Zonal tier runs from 1 TiB to 100 TiB, split into two ranges with different scaling steps.

Both ranges support custom performance, snapshots, backups and replication, and instances can be resized in either direction, which the Basic tiers cannot do.

Unlike the older High Scale SSD tier it replaces for large sizes, Zonal can be resized in both directions, so a first capacity estimate does not lock you in. Zonal also supports non-disruptive upgrades.

Basic HDD is a legacy tier (it replaced the old standard tier) that stores data on hard disks with fixed performance, aimed at file sharing, web hosting and development.

Capacity runs from 1 TiB to 63.9 TiB and can only be increased, in 1 GiB steps. Performance is fixed, with a boost once provisioned capacity passes 10 TiB. It is zonal and supports backups but not snapshots.

When provisioned through the Filestore CSI driver on GKE, the minimum drops to 100 GiB, but anything under 1 TiB still consumes 1 TiB of quota.

Basic SSD is the legacy SSD-backed tier (it replaced premium). It offers higher, fixed performance than Basic HDD: roughly 1,200 MiB/s read throughput and 60,000 read IOPS, regardless of how much capacity you provision.

Capacity runs from 2.5 TiB to 63.9 TiB, scaling up only. It is zonal and supports backups, not snapshots. Because performance does not grow with size, buying more capacity does not make it faster.

Because speed does not rise with size, a 2.5 TiB Basic SSD instance and a 30 TiB one deliver the same limits. If you need more speed as you grow, Zonal with custom performance is the usual path.

The Regional tier is built for applications that need continuous availability and resilience to a zone outage. Data is kept across zones in the region, so a single-zone failure does not take the share offline.

Capacity ranges from 1 TiB to 100 TiB in two ranges, like Zonal. It supports custom performance, snapshots, backups and replication. It cannot be combined with multishares for GKE.

Performance scales with capacity inside each range. For example, a 9.75 TiB Regional instance tops out around 117,000 read IOPS, while a 10 TiB one is limited to about 92,000, because the larger range is tuned differently.

Enterprise is the legacy regional tier, now succeeded by the Regional tier. It stores data redundantly across zones and targets mission-critical workloads such as SAP and VMware datastores.

Capacity is 1 TiB to 10 TiB, resizable up or down in 256 GiB units, and performance scales with capacity. It supports snapshots and backups.

On GKE, Enterprise is the tier behind multishares, which carves one instance into many small persistent volumes.

New designs should use Regional instead. Know Enterprise mainly because older documentation, existing instances, the ENTERPRISE tier value in the API and the multishares feature still refer to it.

A snapshot is a point-in-time, space-efficient copy of an instance's data. It is stored inside the instance as a child resource, and all snapshots of an instance share unchanged data, so only differences consume extra capacity.

Every directory in the share has a hidden .snapshot folder, so you can browse a snapshot and copy individual files back. You can also revert a whole instance to a snapshot.

Snapshots work on Zonal, Regional and Enterprise instances, not on Basic HDD or Basic SSD, with up to 240 snapshots per instance.

A backup is a point-in-time copy of an instance that includes all user data and some instance metadata. It is stored separately from the source instance, so it survives deletion of that instance.

You can create a backup in any region and restore it to an existing instance or a new one in any region. Backups are available on every tier, which makes them the only built-in recovery option for Basic HDD and Basic SSD.

Filestore also integrates with Backup and DR Service if you want centrally managed schedules and retention.

Instance replication asynchronously copies data from a source instance to a standby (replica) instance in a different region, giving you a disaster recovery copy with a low but non-zero recovery point.

It is supported on the Zonal, Regional and Enterprise tiers and is generally available. The replica is read-only while replication runs; to use it you stop replication, which turns it into a normal writable instance.

flowchart LR
  A[Clients] --> B["Source instance - Region 1"]
  B -- async replication --> C["Replica instance - Region 2"]
  C -. stop replication on failover .-> D["Writable instance"]

The Filestore CSI driver lets Kubernetes create and mount Filestore instances for pods. Enable it as a GKE add-on, then reference a StorageClass from a PersistentVolumeClaim and the driver provisions a Filestore instance, or a multishare slice, automatically.

Built-in classes include standard-rwx (Basic HDD), premium-rwx (Basic SSD), enterprise-rwx and enterprise-multishare-rwx. All provide ReadWriteMany volumes, and the driver can also create NFSv4.1 instances.

Under the hood, a controller component calls the Filestore API to create and delete instances, while a node component performs the NFS mount on the node. Check that your driver version supports the features you want, such as NFSv4.1 instances or multishares.

Custom performance lets you set IOPS independently of capacity on Zonal and Regional instances, so a small instance can be fast, or a large one cheap. It is not available on Basic or legacy Enterprise.

You choose either a fixed max-iops or a ratio max-iops-per-tb; throughput and write IOPS are derived from the purchased read IOPS. Each 1,000 purchased IOPS supports up to 100 client connections.

gcloud filestore instances create fast-share --zone=us-central1-a --tier=ZONAL \
  --file-share=name=vol1,capacity=2TB --network=name=default \
  --performance=max-iops=30000

Custom performance instances are billed differently, so check the pricing page before enabling it.

Multishares lets a single Enterprise-tier Filestore instance (1 TiB to 10 TiB) back many small Kubernetes volumes. Each PersistentVolumeClaim gets its own share, with a minimum share size of 10 GiB and up to 80 shares per instance.

Without it, every claim would need its own instance with a 1 TiB minimum footprint. The Filestore CSI driver packs claims into shared instances for you using the enterprise-multishare-rwx StorageClass.

Limits to remember: it cannot be combined with the Regional tier, and reverting an instance to a snapshot is not supported with multishares.

Filestore uses standard IAM roles for the management plane: roles/file.editor can create, update and delete instances, snapshots and backups, while roles/file.viewer can only list and read them.

IAM does not decide who can read files. Data access is controlled separately by the share's NFS export options (allowed IP ranges, read-only or read-write, root squash) and by ordinary POSIX permissions on the files.

A user with file.viewer can see an instance exists but still cannot read its data unless their VM's IP is allowed.

Root squash maps requests from the client's root user to an anonymous, unprivileged uid/gid, so a root user on a VM does not get root powers over the exported files.

The squash mode is set per export rule alongside the allowed IP ranges and access mode: NO_ROOT_SQUASH (the default) keeps root access, and ROOT_SQUASH removes it. You can choose the anonymous identity with anon_uid and anon_gid.

"nfs-export-options": [{
  "ip-ranges": ["10.0.0.0/24"],
  "access-mode": "READ_WRITE",
  "squash-mode": "ROOT_SQUASH",
  "anon_uid": 1003,
  "anon_gid": 1003
}]

Filestore is a file system you mount over NFS. Cloud Storage is an object store you call through an API. That one difference drives most design choices.

Cloud Storage FUSE can mount a bucket like a folder, but it is not a full POSIX file system, so apps needing locks or frequent small in-place writes belong on Filestore.

A Persistent Disk is a block device that you attach to a VM, format and manage yourself. Filestore is a managed file server that many machines mount at once.

If only one VM needs the data, a disk is simpler and cheaper. If several VMs or pods must see the same files, use Filestore.

Both are current-generation tiers with the same capacity range (1 TiB to 100 TiB), custom performance, snapshots, backups and replication. The difference is where the data lives and how performance is tuned.

Throughput per TiB is higher on Zonal, so for pure speed inside one zone Zonal wins. Pick Regional when losing a zone is not acceptable.

Snapshots are quick, in-instance recovery points. Backups are independent copies meant to survive loss of the instance.

A solid plan uses both: frequent snapshots for oops-I-deleted-it fixes, and scheduled backups for real disaster recovery.

Interview tip: snapshots protect against file-level mistakes, not against losing the instance, because they live inside it. That is why production setups schedule snapshots for quick fixes and backups for recovery from instance loss.

NFSv3 is stateless and works with every tier. NFSv4.1 is stateful and adds stronger security, but it is limited to Zonal, Regional and Enterprise instances.

Choose v4.1 when you need in-transit encryption or tidier firewall rules. Choose v3 for Basic tiers or older clients that cannot speak v4.1.

Client support is the practical catch. Check that your Linux kernel and NFS utilities handle v4.1, and keep user identity mapping consistent, because mismatched ID mapping often shows files as owned by nobody.

On Zonal, Regional and Enterprise instances, performance grows linearly with provisioned capacity inside a capacity range. On Basic SSD it is fixed, and Basic HDD only steps up past 10 TiB.

Take the Zonal lower range: 260 MiB/s read throughput, 88 MiB/s write throughput, 9,200 read IOPS and 2,600 write IOPS per TiB. A 4 TiB instance therefore gets about 1,040 MiB/s read and 36,800 read IOPS. In the 10 TiB to 100 TiB range, the figure is 650 MiB/s read per 2.5 TiB, so 10 TiB gives roughly 2,600 MiB/s.

Per-TiB numbers differ by tier and range, and they are upper limits that need enough clients and parallelism to reach. If you need speed without extra capacity, turn on custom performance instead of over-provisioning.

The Filestore server runs in a Google-managed network, so it needs a block of addresses carved out of your VPC's private space to be reachable from your clients. That reserved range keeps the instance's IPs from colliding with your subnets.

When you specify a CIDR directly, its size depends on the tier: /29 for Basic, /24 for legacy High Scale, and /26 for Enterprise. With private services access you instead name an allocated range tied to that connection.

The range must be internal (private) address space and must not overlap existing subnets or ranges used by other Filestore instances in the same VPC. Overlaps are the usual cause of create failures.

There are three connection options, and the one you pick decides how the instance gets its IP address.

1. Direct peering: Filestore peers directly with your VPC and uses a reserved CIDR range you supply.
2. Private services access: the instance uses an allocated range shared with other Google managed services through a private connection.
3. Private Service Connect: a consumer endpoint is created inside your own VPC, with support for NFSv3 or NFSv4.1 and for IPv4 or IPv6.

Clients outside the VPC, such as on-premises hosts, reach the instance over VPN or Interconnect, so make sure routes to the reserved range are advertised.

Use the google_filestore_instance resource and describe the tier, share and network.

resource "google_filestore_instance" "shared" {
  name     = "shared-fs"
  location = "us-central1-a"
  tier     = "ZONAL"

  file_shares {
    name        = "vol1"
    capacity_gb = 1024
  }

  networks {
    network = "default"
    modes   = ["MODE_IPV4"]
  }
}

output "nfs_ip" {
  value = google_filestore_instance.shared.networks[0].ip_addresses[0]
}

capacity_gb = 1024 equals 1 TiB, the minimum for most tiers. For a Regional instance set location to a region. Remember that changing some fields forces a replacement, so review the plan before applying.

Store Terraform state in a remote backend such as a Cloud Storage bucket, and pass the output IP to VM startup scripts or Kubernetes manifests so mounts configure themselves. Use lifecycle { prevent_destroy = true } on production shares.

When a pod claims storage through a Filestore-backed StorageClass, the CSI controller creates the Filestore instance on demand, then the node plugin mounts it.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-data
spec:
  accessModes: ["ReadWriteMany"]
  storageClassName: standard-rwx
  resources:
    requests:
      storage: 1Ti

sequenceDiagram
  participant U as User
  participant K as Kubernetes API
  participant P as CSI provisioner
  participant F as Filestore API
  participant N as Node plugin
  U->>K: Create PVC (standard-rwx)
  K->>P: Provision volume request
  P->>F: Create instance and share
  F-->>P: Instance READY with IP
  P-->>K: Create PV and bind to PVC
  U->>K: Schedule pod using PVC
  N->>F: NFS mount IP:/share into pod

Creating a new instance takes minutes, so the first pod waits in Pending until the claim binds. Deleting the PVC follows the StorageClass reclaim policy, which by default removes the instance and its data.

You cannot shrink it in place. Basic HDD and Basic SSD capacity can only be increased, in 1 GiB steps, so reducing size means migrating to a smaller instance.

1. Create a new, smaller instance, such as a 1 TiB Zonal instance if the data fits.
2. Mount both shares on a VM and copy with rsync -aH --numeric-ids so ownership is preserved.
3. Run a final delta sync while writers are paused, then repoint clients to the new IP.
4. Keep a backup of the old instance for a few days, then delete it.

Zonal and Regional instances can be resized both ways within their step sizes, so moving off Basic also removes this limitation.

Today the honest answer is: rarely for new builds. Basic SSD is a legacy tier with fixed performance and no snapshots, replication or custom performance, and Google notes that a lower-capacity Zonal instance is often a better fit.

Basic SSD still makes sense when you already run it and migration is not worth the risk, or when a simple, fixed-profile share in the 2.5 TiB to 63.9 TiB range meets your needs and its price compares well for your region.

Pick Zonal when you want snapshots, replication, NFSv4.1, non-disruptive upgrades, resizing in both directions, or the ability to start at 1 TiB.

Choose Regional when the application must keep running through a zone failure, such as SAP, ERP, or any production service where losing the file share for hours is unacceptable.

Choose Zonal when the workload is compute-bound batch, HPC or rendering that runs in one zone and can be restarted, and when you want more throughput per TiB.

Keep in mind that Regional still does not protect against a whole-region loss. Pair it with scheduled backups and, if your recovery goals demand it, cross-region replication. Also note Regional cannot be used with multishares for GKE.

Regional usually costs more than Zonal per TiB, so check current pricing and quantify the cost of downtime first. Test a zone-failure scenario to confirm your clients reconnect on their own.

Use multishares when a GKE cluster needs many small ReadWriteMany volumes. Separate instances carry a 1 TiB minimum footprint each, so fifty 20 GiB claims would waste enormous capacity and cost.

With multishares, a 1 TiB to 10 TiB Enterprise instance can host up to 80 shares of at least 10 GiB each.

Stay with dedicated instances when one workload needs guaranteed performance, since shares on one instance compete for the same IOPS and throughput. Dedicated instances are also needed for the Regional tier and for reverting to snapshots, neither of which works with multishares.

A hybrid is common: dedicated instances for a few busy, critical volumes, and one or two multishare instances for the long tail of small application volumes.

You create a replica instance in another region and point it at the source. Filestore copies data asynchronously, so the replica trails the source by a small interval, which is your recovery point objective.

1. Create the replica instance and link it to the source instance.
2. Filestore performs an initial full sync, then ships changes continuously.
3. While replication runs, the replica is read-only.
4. On disaster, stop replication to promote the replica to a normal writable instance, then repoint clients to its IP.
5. After recovery, rebuild replication in the opposite direction to fail back.

sequenceDiagram
  participant S as Source (Region 1)
  participant R as Replica (Region 2)
  participant C as Clients
  S->>R: Initial sync
  loop Continuous
    S->>R: Ship changes (async)
  end
  Note over S: Region failure
  C->>R: Stop replication, promote
  C->>R: Mount replica IP

Because it is asynchronous, expect to lose the last few minutes of writes. Rehearse the promotion and client cutover regularly, since DNS or mount changes are usually the slow part.

Mount the share, find the file in the hidden .snapshot directory, and copy it back. Every directory contains .snapshot, holding the snapshots that apply to that directory.

ls /mnt/vol1/reports/.snapshot/
sudo cp -pa /mnt/vol1/.snapshot/snap2/reports/q3.xlsx /mnt/vol1/reports/

Use -pa so permissions, ownership and timestamps are preserved. Copying over an existing file is destructive, so check that you are restoring the right one.

To roll back the entire share instead, revert the instance to a snapshot. That is only supported on instances with a single share, it deletes snapshots newer than the target, and it changes file handles, so remount clients afterwards.

Schedule snapshots, for example hourly with several days of retention, so there is always a recent copy to pull from. Each snapshot holds old blocks and reduces free capacity, and a restored file keeps its original ownership only if you copy with -p.

A timeout almost always means the client cannot reach the instance. Work from the network outward:

1. Confirm the instance is READY and note its IP with gcloud filestore instances describe.
2. Check the client is in the same VPC or has routes to the reserved range (peering, VPN or Interconnect).
3. Check firewall rules allow NFS traffic. NFSv4.1 needs TCP 2049; NFSv3 also uses the portmapper and helper ports listed in the Filestore firewall docs, commonly 111, 2046 and 4045.
4. Check the share's export options include the client's IP range.
5. Check the NFS client package is installed.

nc -zv 10.0.0.2 2049
showmount -e 10.0.0.2
sudo mount -v -t nfs -o vers=3 10.0.0.2:/vol1 /mnt/vol1

If nc succeeds but the mount still hangs, suspect the export rule or an NFS version mismatch rather than the network.

Permission errors come from three places: the export rule, root squash, and plain POSIX ownership. Check them in that order.

1. Access mode: if your client's IP matches a READ_ONLY rule, every write fails.
2. Root squash: with ROOT_SQUASH, root on the client becomes an anonymous user, so chown and writes into root-owned directories fail.
3. UID/GID mismatch: Filestore stores numeric IDs. If user alice is uid 1001 on one VM and 1002 on another, files look foreign.

Fixes: correct the ranges, temporarily use NO_ROOT_SQUASH to set ownership, set anon_uid and anon_gid to a sensible account, and standardize IDs across clients with a directory service or consistent provisioning.

A fresh share is owned by root, so the first admin task is usually a chown or chmod on the top-level directory.

Filestore's limits are rarely the bottleneck for a single default mount. Tune the client and the layout first.

• Use nconnect on Linux 5.3+ kernels to open several TCP connections per mount; values around 7 are commonly recommended for the faster tiers.
• Add parallelism: performance numbers need many threads or clients, not one serial copy.
• Colocate clients in the same zone as a Zonal instance to cut latency and cross-zone costs.
• Size the VM: a small machine type caps network throughput below what Filestore can serve.
• Right-size the instance or enable custom performance for more IOPS.

sudo mount -o rw,hard,nconnect=7 10.0.0.2:/vol1 /mnt/vol1

fio --name=randread --directory=/mnt/vol1 --rw=randread --bs=4k \
    --iodepth=64 --numjobs=8 --size=2g --runtime=60 --time_based --group_reporting

Always benchmark before and after a change with a tool such as fio, so you know which tweak helped.

Filestore bills for provisioned capacity, so most savings come from provisioning less and keeping less.

1. Right-size: Zonal and Regional can shrink, so trim over-provisioned shares. Basic cannot shrink in place.
2. Match tier to need: do not run Regional for dev and test data that only needs Zonal or Basic.
3. Prune snapshots: they consume instance capacity as files change.
4. Set backup retention: backups are billed on stored size, so expire old ones.
5. Avoid buying IOPS you do not use with custom performance.
6. Tier cold data out to Cloud Storage and delete idle test instances.
7. Use multishares for many small GKE volumes.

Review cost monthly: list instances, compare used versus provisioned capacity in Cloud Monitoring, and label instances by team so idle ones are easy to find and clean up.

The main charge is provisioned capacity per GiB per hour, at a rate that depends on the tier and region. You pay for the size you provisioned even if the share is mostly empty.

Other items can appear on the bill:

• Backups: billed on stored backup size.
• Custom performance: instances using it are billed on a different basis than default-performance ones.
• Network egress: traffic between zones or regions, and replication traffic, can add charges.

Rates change, so read the current Filestore pricing page and use the Google Cloud pricing calculator when sizing a project.

Example: a 2 TiB instance provisioned for a full month is billed for 2 TiB the whole time, even if only 200 GiB is used. Resizing a Zonal or Regional instance down lowers the bill going forward, while a Basic instance stays at its high-water mark.

New writes fail with No space left on device (ENOSPC), while reads continue to work. Applications that do not handle write errors may crash or silently lose data.

On instances that support snapshots, space can vanish faster than expected, because snapshots keep old blocks and available capacity drops as files change.

To recover, increase capacity, delete old snapshots, or remove data:

gcloud filestore instances update nfs-demo --zone=us-central1-a --file-share=name=vol1,capacity=2TB

Basic tiers can only grow; Zonal and Regional can grow or shrink. Prevent surprises by alerting in Cloud Monitoring on the instance's used-capacity percentage well before 100%.

Set a Cloud Monitoring alert on used capacity at around 80 percent. Expanding a share does not shrink snapshot usage, so clean up old snapshots and large temp directories at the same time as the resize.

Data at rest is always encrypted, by default with Google-managed keys. You can switch to customer-managed encryption keys (CMEK) in Cloud KMS for tighter control.

In transit the picture depends on the protocol. NFSv3 is not encrypted, so traffic inside the VPC travels in the clear between client and instance. NFSv4.1 supports Kerberos-based security flavors that can add integrity and privacy protection.

For regulated workloads, combine CMEK with tight IAM on the key and Cloud Audit Logs on KMS, and prefer NFSv4.1 with Kerberos when data crossing the network must be protected. Keep the instance on private networking only.

You create the key in Cloud KMS, let Filestore use it, and reference it when creating the instance.

1. Create a key ring and key in the same location as the Filestore instance.
2. Grant the Filestore service agent for your project the roles/cloudkms.cryptoKeyEncrypterDecrypter role on that key.
3. Create the instance with the key reference.

gcloud filestore instances create secure-fs --zone=us-central1-a --tier=ZONAL \
  --file-share=name=vol1,capacity=1TB --network=name=default \
  --kms-key=projects/PROJECT/locations/us-central1/keyRings/fs-ring/cryptoKeys/fs-key

Disabling or destroying the key makes the data unreadable, which is the point for compliance but a risk for operations, so protect the key with IAM and rotation policies. Check the docs for which tiers currently support CMEK.

Operationally, rotate keys on a schedule and monitor key state, because an accidentally disabled key can make a production share unavailable. Confirm how backups of a CMEK instance are protected before a compliance review.

Limits differ between the Basic tiers and the newer tiers, and are worth knowing for capacity planning.

Google notes there is no hard cap on file counts, but performance can slow with very large numbers of files, so keep directory fan-out reasonable. Always verify figures against the current quotas page, since they change.

Design takeaway: one directory holding millions of entries slows listing and metadata operations, so spread files across hashed subdirectories. The 16 TiB single-file cap on Basic rarely matters outside database dumps or genomics data.

Treat it as a copy-then-cutover project and preserve ownership and permissions.

1. Size it: measure data volume and file count, then pick a tier and capacity with headroom.
2. Connect: link on-premises to the VPC with Cloud VPN or Interconnect.
3. Initial copy: run parallel rsync jobs, or use Storage Transfer Service agents for POSIX file systems when you need managed, resumable transfers.
4. Delta syncs: repeat until the change set is small.
5. Cutover: pause writers, run a final sync, verify counts or checksums, then repoint applications.

sudo rsync -aH --numeric-ids --info=progress2 /srv/export/ /mnt/filestore/vol1/

Keep the old system read-only for a rollback window before decommissioning it.

Plan for permissions early: if the source uses NIS or LDAP identities, the same numeric IDs must resolve on Google Cloud clients, or files will look wrongly owned after the move. Throttle the copy so production NFS is not overwhelmed.

No. Filestore is an NFS-only service, with NFSv3 and NFSv4.1, and does not offer SMB shares.

Your options for Windows file sharing on Google Cloud are:

• Google Cloud NetApp Volumes, a managed service that supports SMB as well as NFS.
• A Windows file server running on Compute Engine with a Persistent Disk.
• Cloud Storage through an application or gateway, if file-system semantics are not required.

A Windows machine can use an NFS client, but that tends to be a niche setup with permission-mapping quirks, so SMB-first workloads are better served by one of the options above.

If your Windows app can move to a Linux client, NFS on Filestore is fine. If Windows and Linux must share the same files with Windows ACLs, NetApp Volumes is the more natural design.

Zonal instances support non-disruptive upgrades (NDUs): Google patches and upgrades the service behind your instance without taking the share offline, so mounted clients keep working through the change.

By contrast, Basic tier instances are documented as having maintenance limitations, so a brief pause in I/O is possible during maintenance.

Make clients resilient either way by using hard mounts. With hard, the NFS client retries instead of returning errors to the application, so a short stall looks like latency, not failure. A soft mount can surface I/O errors and corrupt in-flight writes.

10.0.0.2:/vol1 /mnt/vol1 nfs rw,hard,_netdev 0 0

For operations teams: watch Filestore release notes and service health for upgrade announcements, test application behavior during a brief I/O pause in staging, and prefer Zonal or Regional over Basic for services that cannot tolerate pauses.

It depends on access pattern. Filestore wins for small random reads, many small files, checkpoints and tools that need real POSIX behavior. Cloud Storage FUSE wins on cost and capacity for large, mostly sequential datasets that live in buckets anyway.

Many teams combine them: keep the master dataset in a bucket, stage the hot subset onto Filestore for training, and write checkpoints there.

Layer protection so each failure type has an answer.

1. Zone failure: use the Regional tier and place client VMs or GKE nodes across several zones.
2. Human error: take scheduled snapshots, so files can be restored from .snapshot.
3. Instance loss or corruption: schedule backups to another region.
4. Region failure: add cross-region instance replication to a standby instance.
5. Client resilience: use hard mounts and infrastructure-as-code to repoint clients quickly.

flowchart TD
  A["Clients in zones a, b, c"] --> B["Regional Filestore - Region 1"]
  B -- snapshots --> B
  B -- scheduled backups --> C["Backups in Region 2"]
  B -- async replication --> D["Standby instance - Region 2"]
  D -. promote on disaster .-> E["Writable DR instance"]

Define your RTO and RPO first, then rehearse the failover. Replication is asynchronous, so a regional failover can lose the most recent writes.