# Filestore

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/filestore

## Quick definition

Google Cloud Filestore is a service that provides managed file storage in the cloud. It allows multiple virtual machines to access the same files at the same time, similar to how a shared network drive works in an office. You can use it for applications like content management systems, data analytics, or any workload that requires a shared file system.

## Simple meaning

Imagine you work in a busy office with several colleagues. Each person has their own computer, but you all need to work on the same set of documents, spreadsheets, and project files. If every document is stored only on one person's computer, no one else can reach it. The solution is a shared network drive, a central folder that everyone’s computer can connect to. Google Cloud Filestore is exactly that, but for virtual machines running in the cloud.

Instead of documents, your virtual machines store application data, logs, configuration files, or media assets. Filestore uses a standard protocol called NFS (Network File System). This is like the rules that allow different computers to talk to each other and share files. Once you create a Filestore instance, you get a stable IP address. Your virtual machines can then "mount" that IP address, meaning they treat the remote storage as if it were a local drive. Any file written by one machine is immediately visible to all others.

There are no hard drives inside Filestore that you need to replace. Google takes care of the physical disks, backups, and redundancy. You simply choose how much storage you want and how fast it should be. Filestore is useful for many real-world tasks: running a website that stores user uploads, hosting a shared database volume, or providing a home directory for employees in a remote office. It is designed for situations where multiple servers need constant, low-latency access to the same set of files. Unlike object storage like Google Cloud Storage, Filestore behaves like a traditional file server, you can use standard file commands (open, read, write, delete) and it supports file locking and permissions.

## Technical definition

Google Cloud Filestore is a fully managed, high-performance file storage service that provides native NFS (Network File System) protocol support for Compute Engine and Google Kubernetes Engine (GKE) workloads. It is based on the NFSv3 server daemon, which runs on Google-managed infrastructure. When you create a Filestore instance, you choose a service tier (Basic HDD, Basic SSD, High Scale SSD, Enterprise) and a capacity. The instance is provisioned with a fixed IP address on a private RFC 1918 subnet within your Virtual Private Cloud (VPC) network. Clients access the share by mounting the NFS export path, usually via an /etc/fstab entry or a kubectl PersistentVolume definition.

Under the hood, Filestore uses a distributed file system architecture. Data is stored redundantly across multiple physical disks and availability zones (for Enterprise tier). The NFS protocol handles file locking (advisory locking via locks) and access control using standard Unix permissions (uid, gid, mode bits) and optionally NFSv4 ACLs. Performance scales with capacity: larger instances provide more throughput and IOPS. For example, a 1TB High Scale SSD instance offers 1GB/s read throughput and 200K read IOPS.

Filestore supports snapshots for point-in-time data protection. You can create a snapshot of a volume and later restore it to a new instance. For backups, you can use gcloud filestore backups commands to create manual or scheduled backups. Encryption at rest and in transit is enabled by default using Google-managed keys, or you can use Customer-Managed Encryption Keys (CMEK). Access is controlled via IAM roles (like roles/file.editor) and VPC firewall rules. NFS traffic (port 2049 for NFS, port 111 for portmapper) must be allowed between client and server subnets.

In a real IT implementation, you might deploy a web application on multiple Compute Engine instances behind a load balancer. All instances mount the same Filestore share to store user-uploaded files or session data. For high performance, you choose an Enterprise tier with SSD storage and enable your clients to use the NFS hard mount option to avoid stale file handles. You must also configure the mount options correctly (rsize=1048576, wsize=1048576, hard, intr) for optimal throughput. Filestore is not POSIX-compliant for all semantics (e.g., it does not support extended file attributes in NFSv3), but it works well for most shared-file workloads.

## Real-life example

Think about a family photoshoot business. The photographer has three employees: one does editing on a powerful desktop, one handles album design on a laptop, and the third manages prints on another computer. Instead of saving finished photos on each machine separately, they store everything on a central shared drive that sits in the office. Everyone connects to that drive over the local WiFi. When the editor finishes retouching a photo and saves it, the album designer can see it immediately without any manual copying. That is what Filestore does in the cloud.

Now imagine a scenario where the family photography business grows and opens a second office in another city. They still want everyone to access the same photo library without emailing files back and forth. Setting up a physical drive in one office means the other office has slow access over the internet. With Google Cloud Filestore, both offices can create virtual machines (or even connect their on-premises computers via VPN) and mount the same Filestore share. The cloud becomes the central filing cabinet. The editors in New York and the album designers in London can work on the same files at the same time, and changes are visible within seconds.

In this analogy, Filestore is the cloud-based filing cabinet. The NFS protocol is the way the computers talk to the cabinet, like having the right key and knowing the correct shelf number. The IP address is the cabinet’s location. The capacity (TB) is how many photo albums you can store. The performance tier (HDD or SSD) is like choosing a cabinet with slow drawers (HDD) or fast sliding drawers (SSD). The security settings (IAM, firewall rules) decide who is allowed to open the cabinet and which employees can read, write, or delete photos. By using Filestore, the business avoids buying and maintaining physical storage hardware, can scale up easily when they get more clients, and keeps all the team in sync.

## Why it matters

In modern IT infrastructure, applications rarely run on a single server. Web applications, content management systems (like WordPress or Drupal), and many enterprise tools require multiple compute instances to handle traffic and provide redundancy. These instances need a common place to store uploaded files, configuration data, or session information. Without a shared file system, each instance would have to store its own copy, leading to data inconsistency. For example, if a user uploads a profile picture on server A, but the next request goes to server B, that picture would be missing. Filestore solves this by providing a single, consistent file store that all instances can access simultaneously.

Filestore is also critical for lift-and-shift migrations. Many on-premises applications were written expecting a local or network file system (like an NFS mount). When moving to the cloud, you cannot simply drop them into object storage without rewriting code. Filestore offers a drop-in replacement with the same NFS interface, making migration faster and less risky. It also supports high-performance workloads like media rendering, financial modeling, and genomics analysis where low-latency file access is essential.

From a cost perspective, Filestore eliminates the overhead of managing physical NAS devices. You no longer need to provision disks, configure RAID, monitor disk health, or handle failovers. Google handles all that. You only pay for the provisioned capacity (even if you don’t use all of it) plus any snapshots or backups you take. This makes budgeting simpler and reduces operational burden, especially for small teams. The ability to scale storage independently from compute also gives you flexibility: you can increase Filestore capacity without adding more virtual machines, or you can delete instances when not needed.

## Why it matters in exams

While Google Cloud Filestore is not a core topic for general entry-level IT certifications like CompTIA A+ or Network+, it can appear in more advanced Google Cloud-specific exams or broader cloud architecture exams. For the Google Cloud Associate Cloud Engineer exam, you should understand when to use Filestore versus Cloud Storage versus Persistent Disk. The exam objectives include designing storage solutions for different workloads, and a scenario question might ask: “Your application requires a shared file system that supports NFSv3. Which service should you choose?” The correct answer is Filestore. You might also see questions about performance tiers: which tier is best for high-throughput workloads (High Scale SSD) or for capacity-optimized workloads (Basic HDD).

For the Google Cloud Professional Cloud Architect exam, Filestore is more likely to appear in design scenarios. You might be given a migration plan for an on-premises ERP system that uses NFS mounts. You would need to recommend Filestore for a minimal-code migration. Questions could also touch on security: how to restrict access to Filestore using VPC firewall rules and private IPs, or how to encrypt data with CMEK. Multi-region availability might be tested: only Enterprise tier supports regional (multi-zone) redundancy. You could also see questions about backup strategies: using snapshots or scheduled backups for disaster recovery.

For certification exams like the AWS Solutions Architect or Azure Administrator, Filestore is not directly tested (those clouds have their own equivalents like Amazon EFS or Azure Files). But the concept of managed NFS storage is a common theme. If you are cross-training, understanding Filestore helps you compare cloud file services. For general IT certification exams like the Linux Professional Institute (LPIC) or Red Hat Certified Engineer (RHCE), you may not need to know Filestore by name, but you should know how to mount an NFS share in Linux, that skill directly applies when connecting to Filestore. The exam objectives for those Linux exams often include “configure autofs to mount network file systems.” In that context, a question might present an NFS export path (like 10.0.0.5:/vol1) and ask you to configure a permanent mount in /etc/fstab. That is exactly how you would use Filestore in real life.

## How it appears in exam questions

Exam questions about Filestore typically fall into three patterns: scenario-based selection, configuration, and troubleshooting.

Scenario-based selection: The question describes an application that runs on multiple Compute Engine instances and needs to share files. It will give constraints like “must use NFS protocol,” “must support concurrent writes from multiple clients,” or “must provide high throughput for media processing.” The answer choices will include Cloud Storage, Persistent Disk, Filestore, and maybe Cloud SQL. The correct answer is Filestore. A trick variant might suggest using a single Persistent Disk attached to all instances, which is not possible because Persistent Disk can attach to only one instance in read-write mode (or multiple in read-only). Another distractor might be Cloud Storage FUSE, but that uses HTTP and does not provide full file locking.

Configuration questions: You may be asked to complete a command to mount a Filestore instance on a Linux VM. For example: “You have a Filestore instance with IP 10.0.0.2 and export path /vol1. Which command should you run on the VM to mount it to /mnt/data?” The answer is: sudo mount -t nfs 10.0.0.2:/vol1 /mnt/data. You might also be given an /etc/fstab entry and asked to identify the correct syntax: 10.0.0.2:/vol1 /mnt/data nfs defaults, hard, intr 0 0. Another variant asks about enabling automatic mounting at boot, you would ensure the mount point exists and the entry is in /etc/fstab.

Troubleshooting questions: A VM cannot connect to a Filestore instance. The question gives a firewall rule that only allows traffic on port 22. You must identify that NFS requires port 2049 and optionally port 111 (portmapper). The fix is to add a firewall rule allowing ingress from the VM subnet to the Filestore subnet on those ports. Another scenario: a user reports very slow file transfers. The question describes the VM has a low network bandwidth or the Filestore instance is a Basic HDD tier. The solution is to upgrade to a higher tier (SSD) or ensure the VM is in the same region and zone as the Filestore instance (or has optimized connectivity). You might also see questions about mount options: using “soft” mount can cause file corruption if the server becomes briefly unreachable, while “hard” mount will retry until the connection is restored. The exam may ask which mount option is recommended for critical data. The answer is “hard” (with intr).

## Example scenario

You are a system administrator at a university. The IT department has built an online course portal where students can upload their homework assignments as PDF files. The portal runs on two Compute Engine instances in Google Cloud to handle high traffic during submission deadlines. The web application stores the uploaded files in a directory called /var/www/uploads. If each instance has its own local disk, a student might upload a file to instance A, but when the professor tries to download it later, the request might go to instance B, and the file would not be found.

To fix this, you decide to use Google Cloud Filestore. You create a Basic SSD Filestore instance with 2 TB capacity in the same region as your VMs. You note the IP address (say, 10.0.0.4) and the export path (/vol1). On both Compute Engine instances, you log in via SSH and run the following commands: sudo mkdir -p /mnt/uploads, then sudo mount -t nfs 10.0.0.4:/vol1 /mnt/uploads. You also configure the web application to use /mnt/uploads as the upload directory. To ensure the mount persists after reboot, you add the line 10.0.0.4:/vol1 /mnt/uploads nfs defaults, hard, intr 0 0 to /etc/fstab.

Now, when a student uploads a PDF, the file is written to Filestore. If the second VM receives the download request, it reads the same file from the same Filestore share. Everything works seamlessly. Later, the professor asks for a backup of all homework submissions. You create a snapshot of the Filestore volume from the Google Cloud Console, and store it in a different region for disaster recovery. The solution is simple, cost-effective, and saves you from having to rewrite the application’s file handling code.

## Common mistakes

- **Mistake:** Thinking Filestore is the same as Cloud Storage (object storage).
  - Why it is wrong: Cloud Storage stores objects (blobs) with a flat namespace, not files in a hierarchical directory. It does not support standard file operations like appending, or file locking. It also uses HTTP/HTTPS access, not NFS. Filestore provides a POSIX-like file system with inodes and metadata.
  - Fix: If your application expects a file system that can be mounted via NFS and supports file locks, choose Filestore. If you need high durability, low-cost storage for static assets that are accessed via web URLs, choose Cloud Storage.
- **Mistake:** Attaching a single Persistent Disk to multiple VMs in read-write mode.
  - Why it is wrong: Google Cloud Persistent Disk can be attached to multiple instances only in read-only mode. It does not support concurrent writes. Multiple writers would corrupt the data. Filestore is designed for multi-client read-write access.
  - Fix: Use Filestore when you need multiple Compute Engine instances to read and write to the same file system simultaneously. Use Persistent Disk when only one VM needs read-write access (or multiple VMs need read-only).
- **Mistake:** Assuming Filestore provides automatic global redundancy like Cloud Storage.
  - Why it is wrong: Filestore Basic and High Scale tiers are zonal resources, they exist in one zone. If that zone goes down, the Filestore instance becomes unavailable. Only the Enterprise tier provides multi-zone (regional) redundancy. Cloud Storage is globally available by default.
  - Fix: If high availability is critical, use the Enterprise tier or implement a backup and restore strategy using snapshots and a second instance in a different zone. For non-critical workloads, Basic SSD with scheduled backups may be sufficient.
- **Mistake:** Forgetting to open firewall ports for NFS.
  - Why it is wrong: By default, VPC firewall rules block incoming traffic to NFS ports (2049 and 111). Without proper rules, the VM cannot connect to the Filestore instance, even if the mount command is correct. The user may see a “mount.nfs: Connection timed out” error.
  - Fix: Create a firewall rule that allows ingress traffic from your client VMs' subnets to the Filestore instance's subnet on TCP ports 111 and 2049. You can also enable tcp/udp, but NFSv3 typically uses TCP port 2049.

## Exam trap

{"trap":"In an exam question, a scenario describes an application that needs a shared file system with NFS support, but the storage options include a single Persistent Disk and a Filestore instance. The question asks: 'Which storage should you use?' Many test-takers choose Persistent Disk because they think 'persistent' means 'always available,' but they overlook the requirement for multiple writers.","why_learners_choose_it":"Learners remember that Persistent Disk is a commonly used storage option for Compute Engine instances and assume it can be attached to multiple VMs in read-write mode. They may not have internalized the limitation that Persistent Disk supports only one writer.","how_to_avoid_it":"Memorize the rule: Persistent Disk is for single-writer scenarios, Filestore is for multi-writer shared file systems. On the exam, read the question carefully, if it says 'multiple instances need to read and write to the same storage,' the answer is Filestore. If it says 'one instance needs high-performance local storage' or 'multiple instances need read-only access,' Persistent Disk is acceptable."}

## Commonly confused with

- **Filestore vs Cloud Storage:** Cloud Storage is an object storage service for unstructured data, accessed via HTTP/HTTPS or gsutil. It is not a file system and does not support NFS or file locking. Filestore provides a mountable file system with standard file operations. Use Cloud Storage for backups, static website assets, or data lakes; use Filestore for applications that require a shared file system. (Example: Hosting a website's user-uploaded images on Cloud Storage vs. hosting a shared WordPress installation (which needs a file system) on Filestore.)
- **Filestore vs Persistent Disk:** Persistent Disk is a block storage device that attaches to a Compute Engine instance as a virtual disk. It can only be mounted in read-write mode by one instance at a time. Filestore is a managed file server that many instances can mount simultaneously via NFS. Use Persistent Disk for the operating system or high-performance application data that does not need to be shared; use Filestore for shared data. (Example: A database server using Persistent Disk for its data directory, but a web server cluster using Filestore to share uploaded files.)
- **Filestore vs Google Cloud Filestore vs. Amazon EFS:** Both are managed NFS file systems in the cloud, but they belong to different providers. On Google Cloud the service is called Filestore; on AWS it is called Elastic File System (EFS). The concepts are very similar: scalable, shared file storage for multiple EC2 instances. For GCP exams, you only need to know Filestore; for AWS exams, you need EFS. (Example: Migrating an on-premises NFS workload to GCP uses Filestore; migrating the same workload to AWS uses EFS.)

## Step-by-step breakdown

1. **Create a Filestore instance.** — In the Google Cloud Console, navigate to Filestore and click 'Create Instance'. You choose a name, region and zone, a virtual private cloud (VPC) network, and a subnet where the NFS server will get its IP address. You also select a capacity size and a service tier (e.g., Basic SSD or High Scale SSD). The tier determines performance and cost. After creation, the console shows the NFS mount point like 10.0.0.2:/vol1.
2. **Configure firewall rules.** — For Compute Engine clients to reach the Filestore instance, VPC firewall rules must allow ingress traffic from the client subnet to the Filestore subnet on NFS ports: TCP port 2049 (NFS) and TCP port 111 (portmapper). You can create a rule with source IP range equal to the client VMs' subnet and target tags or service accounts. Without this, the mount will fail.
3. **Prepare the client VM.** — On each Linux VM that needs access, install the NFS client utilities if not already present (sudo apt install nfs-common on Debian/Ubuntu or sudo yum install nfs-utils on CentOS/RHEL). Create a mount point directory, for example sudo mkdir -p /mnt/data. This directory will be the local path that points to the remote Filestore share.
4. **Mount the Filestore instance.** — Run the mount command: sudo mount -t nfs 10.0.0.2:/vol1 /mnt/data. The -t nfs specifies the protocol. You can add mount options like hard (retry until IO succeeds) and intr (allow interrupts while waiting). After this, any file written to /mnt/data is actually stored on Filestore and visible to other clients.
5. **Configure automatic mount on boot.** — Add an entry to /etc/fstab so that the mount persists after a reboot. The line should look like: 10.0.0.2:/vol1 /mnt/data nfs defaults, hard, intr 0 0. You can test the configuration by rebooting or running sudo mount -a. If there are errors, check firewall rules and network connectivity.
6. **Verify and manage access.** — After mounting, test by creating a file from one client (touch /mnt/data/testfile) and checking it exists from another client (ls /mnt/data). For security, use IAM roles to control who can create or delete Filestore instances. Use VPC firewall rules to restrict which source IPs can connect. Optionally, set up snapshots for backup.

## Practical mini-lesson

Google Cloud Filestore is a fully managed NFS file server that runs on Google’s infrastructure. When you use it in practice, you are essentially outsourcing the complexity of a traditional NAS (Network Attached Storage) device. The service handles disk failures, data replication (in Enterprise tier), and performance scaling. As a professional, you need to understand two key aspects: capacity and performance tiers, and network configuration.

First, capacity and performance. Filestore Basic HDD provides cost-effective storage for large volumes of data that do not require fast access (e.g., archival logs or backup staging). Basic SSD offers better performance for general-purpose workloads. High Scale SSD is designed for high-throughput applications like media processing, with up to 1000 MB/s throughput per TB. Enterprise SSD adds multi-zone redundancy and higher IOPS. Your choice affects cost: Basic HDD is cheapest per GB, while High Scale SSD and Enterprise are more expensive but deliver much better performance. The exam might ask: “Which tier provides regional redundancy?” Answer: Enterprise.

Second, network configuration is critical. Filestore is accessed via a private IP address, so your VMs must be in the same VPC network (or connected via VPC peering or VPN). The NFS protocol uses ports 111 and 2049. You must ensure no firewall rules block this traffic. A common mistake is having a “deny all” rule on the VPC ingress. Always add an allow rule for the client subnets. Also, the Filestore instance must be in the same region as your clients to keep latency low. Cross-region NFS mounting is technically possible but will have high latency and is not recommended.

What can go wrong? The most frequent issue is a connection timeout caused by misconfigured firewalls. Another issue is depleted throughput: if you have too many clients accessing the same Filestore instance, you may hit performance limits. You can monitor this in Cloud Monitoring (IOPS, throughput). If you need more performance, you must increase capacity (larger instances provide more throughput) or migrate to a higher tier. Also, be aware that Filestore does not support NFSv4 fully (it supports some features but not all, like delegation). For most applications, NFSv3 is sufficient.

Finally, backup and recovery. Filestore snapshots are quick and space-efficient (only changes are stored). You can schedule automatic snapshots via the gcloud command or using a cron job that calls gcloud filestore snapshots create. Restoring a snapshot creates a new Filestore instance from the snapshot; you cannot revert an existing instance to a previous state. Plan your backup retention policies accordingly.

## Memory tip

Remember: Filestore = File sharing for many stores (many VMs). Think of it as a central filing cabinet in the cloud that everyone can open at the same time.

## FAQ

**Can I mount the same Filestore instance from both Compute Engine and on-premises servers?**

Yes, if you have a Cloud VPN or Cloud Interconnect between your on-premises network and your VPC, you can mount the Filestore share using the same NFS commands. The on-premises server must have network access to the Filestore IP on ports 111 and 2049.

**What happens if I run out of capacity on my Filestore instance?**

You cannot shrink a Filestore instance, but you can increase its capacity at any time without downtime. To increase, edit the instance in the console or use gcloud filestore instances update. The price will adjust accordingly.

**Is Filestore backed up automatically?**

No, automatic backups are not enabled by default. You must configure scheduled backups using Cloud Scheduler, or manually create snapshots. Filestore does offer a backup service that creates full backups of the file system.

**Can I use Filestore with Windows VMs?**

Filestore natively supports NFS, which is available in many Linux distributions. Windows VMs on Compute Engine can mount NFS shares only if you install third-party NFS client software (like Windows Services for NFS) or use a Windows NFS client feature. Google recommends using Linux VMs for Filestore mounts.

**What is the difference between Filestore Basic and High Scale tiers?**

Basic SSD and HDD are designed for general-purpose workloads with up to 100 MB/s throughput per TB. High Scale SSD offers higher throughput (1 GB/s per TB), lower latency, and better IOPS, making it suitable for high-performance computing and media processing.

**Can I access Filestore from outside the VPC without VPN?**

No, Filestore uses a private IP address and does not have a public endpoint. You must connect to it from within the same VPC, or via VPN or Interconnect. You cannot expose Filestore directly to the internet.

## Summary

Google Cloud Filestore is a managed file storage service that provides a shared NFS mount point for multiple Compute Engine instances or GKE pods. It eliminates the need to manage a physical NAS device by offering scalable capacity, multiple performance tiers, and built-in redundancy options. The key takeaway for IT certification exams is understanding when to use Filestore instead of Cloud Storage or Persistent Disk. Filestore is the right choice when you need a file system that supports concurrent reads and writes from multiple clients, with file locking and standard POSIX semantics.

In the real world, Filestore enables lift-and-shift migrations of legacy applications that require NFS, and it powers distributed applications like content management systems, media rendering farms, and shared development environments. It integrates with IAM for access control and VPC firewall rules for network security. The service also supports snapshots and backups for data protection, though you must configure these yourself.

For your exam preparation, focus on the differences between Filestore, Cloud Storage, and Persistent Disk. Know the command to mount a Filestore instance (mount -t nfs IP:/export /mountpoint). Understand that Filestore Basic and High Scale tiers are zonal, while Enterprise is regional. Remember to open firewall ports 111 and 2049. With this knowledge, you will correctly answer scenario-based questions and avoid common traps like choosing Persistent Disk for multi-writer workloads. Filestore is a powerful but straightforward service, once you grasp its purpose, you will see it reappearing in cloud architecture discussions again and again.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/filestore