Maintain Filestore instances

This page provides an overview of maintenance for Filestore instances. It covers maintenance categories, tier impact, network persistence, and best practices.

Overview

Filestore routinely updates instances to ensure that the file share service is reliable, secure, and up-to-date. Maintenance updates typically occur every one to two weeks.

Filestore maintenance is fully managed by Google. You can't configure custom maintenance windows, or manually defer or reschedule maintenance.

Maintenance updates fall into the following categories:

  • Filestore software updates: System optimizations, performance improvements, and new features.
  • Operating system patches: Continuous monitoring and patching of underlying virtual machine (VM) operating systems to protect against security vulnerabilities.
  • Infrastructure upgrades: Underlying virtual machine migrations, hardware maintenance, and network updates.

Maintenance impact by service tier

The impact of a maintenance update depends on your instance's service tier.

Because Basic tier instances experience brief downtime during maintenance, we recommend using Basic tier primarily for development, testing, and non-critical workloads. For production workloads that require high availability and uninterrupted file access, use Regional, Enterprise, or Zonal tiers.

Zonal, Regional, and Enterprise tiers

Zonal, Regional, and Enterprise service tiers use non-disruptive upgrades (NDU).

During maintenance, instances in these tiers remain fully available and continue serving file requests with near-zero downtime. Maintenance updates are applied in the background, making the upgrade process transparent to connected Network File System (NFS) clients.

Basic tiers

Basic tier instances are backed by single-node storage without automated failover. When underlying host migrations, system patches, or software updates occur, file operations pause temporarily until the update completes.

During a maintenance event, Basic HDD and Basic SSD tier instances undergo a brief period of unavailability that typically lasts between 2 and 5 minutes.

During this maintenance window:

  • File operations, such as reads, writes, and directory listings, temporarily pause or freeze.
  • Connected clients that use default retry mechanisms wait for the instance to resume responding.

Network and instance persistence

The internal IP address assigned to your Filestore instance remains persistent throughout maintenance and doesn't change. Connected NFS clients don't need to update mount configurations or remount file shares after an update.

Service level agreement (SLA)

In accordance with the Filestore Service Level Agreement (SLA), downtime resulting from scheduled maintenance is excluded from downtime calculations.

Best practices for handling maintenance

Because you can't schedule or delay Filestore maintenance, configure your NFS clients and infrastructure to handle transient unavailability gracefully:

  • Use hard mounts: When mounting a Filestore file share on a client, specify the hard mount option rather than soft. With a hard mount, if the file server becomes temporarily unavailable, the NFS client retries requests indefinitely until the server responds. This preserves data integrity and prevents application I/O errors.
  • Configure NFS client timeouts and retries: Configure timeout and retransmission mount options on your NFS clients so that transient delays during maintenance don't cause client timeouts.
  • Implement application retries: Build retry logic with exponential backoff into your client applications to handle temporary storage delays smoothly.
  • Monitor instance health and maintenance: Monitor instance performance and status in the Google Cloud console or by using Cloud Monitoring. On Basic tier instances, you might observe a brief latency spike or temporary pause in file operations during the update window.

What's next