Overview of backups

This page describes what a backup is, how it works, some common use cases, and best practices when creating and using backups. To learn how to create and manage backups, as well as how to restore a Filestore instance from a backup, see Back up data for disaster recovery.

What is a backup?

A Filestore backup is a copy of a file share that includes all file data and metadata of the file share from the point in time when the backup is created. Once a backup of a file share is created, the original file share can be modified or deleted without affecting the backup. A file share can be restored from a backup as a new Filestore instance or onto an existing file share.

Backups are regional resources that remain within the region that you specify at the time of creation. You can create backups in the same region as the Filestore instance or in another region for cross-region redundancy. Backups are globally addressable and can be used to restore file shares to any region, but they cannot be shared across projects.

Backup creation

Backups within a region are created incrementally based on previous backups. The first backup you create is a complete copy of the file share. Subsequent backups include only the changes that are not contained in the previous backup. Unchanged data contained in previous backups are referenced in, but not copied to, newer backups. If an older backup is deleted, its unique data is copied to the next most recent backup and all internal data references are automatically updated.

Backup creation is instantaneous, but it takes a period that's proportional to the amount of data being copied before the backup is available for use. During this period, the backup transitions through three states:

State Duration Description
Creating A few seconds Capturing the current state of the file share. Any new changes to file share data may or may not be included in the backup. Stable writes acknowledged by the instance before the backup is initiated are included.
Finalizing Depends on size Uploading data to the backup. Any new changes to file share data are not included in the backup.
Ready Until the backup is deleted The backup is ready for use.

Backups are automatically compressed once created to reduce cost. Taking a backup does not affect the availability or performance of the Filestore instance.

Backup consistency

Filestore backups have NFSv3 consistency semantics. Before a backup is initiated, any write that the Filestore instance acknowledges as written to stable storage or that is followed by an acknowledged COMMIT is included in the backup. For details, see NFSv3 RFC-1813 section 3.3.7.

Common use cases

Backing up data for disaster recovery

Imagine that you have a Filestore instance in us-west1-c, and you want to protect your data against disasters that affect this region. You can schedule a job that regularly creates backups of this instance to a remote region, say us- east1. If a disaster occurred involving us-west1-c, you can create a new instance in another location from any previous backup.

Backing up data to protect against accidental changes

If you want to protect your Filestore data against unintended changes, you can schedule a job that regularly creates backups of the instance. If you lose data, you can browse through the list of backups to identify the one with the version of the file needed. Then, you can create a new Filestore instance from the backup, mount it to the same client as the original instance, and copy the file over.

You can also use the diff command on the two mount points to check the differences between the data on the original instance and the data restored from the backup. Once the data is recovered, you can delete the restored instance and the backup is preserved for future use.

Alternatively, you can do an in-place restore where the backup data is directly restored to the original Filestore instance, replacing all data on it with data from the backup. We recommended that you create a backup of the latest data before performing an in-place restoration because any unbacked data is lost.

Creating clones for development and testing

Imagine you have a database set up on a Filestore instance that serves production traffic. If you want to run a test with a database as an input, you can create a new Filestore instance from a backup of the production instance for the test. In this way, test usage does not interfere with production.

Similarly, you can use backups for offline analysis and investigation without affecting production.

Migrating Data

Once you create a Filestore instance, you cannot change its location or service tier. To migrate your data to another region, you can create a backup of it and use the backup to create a new Filestore instance or restore it to an existing instance.

Also, when you create a new Filestore instance from a backup, you can choose between Basic HDD and Basic SDD tiers regardless of the tier of the source instance.

Best practices

Preparing your file share for the best backup consistency

The quality of a backup depends on the ability of your application to recover from backups that are created during heavy write workloads. In most situations, you can create backups that have good consistency even while your applications write data to the file share. However, if your applications require strict consistency, we recommend doing one or more of the following:

  • Use sync mount. For more information, see "The sync mount option" section in nfs(5). Alternatively, you can open files with the O_DIRECT|O_SYNC flags. For more information, see open(2).
  • Pause applications or operating system processes that write data to the file share and cause them to flush their changes to the file share before initiating the backup. For more information, see fsync(2).
  • If your applications require consistency between multiple shares, pause all applications on all instances that are writing to all file shares and create backups of all file shares before resuming your applications.
  • If you require application level consistency, stop your applications and unmount the file share before creating a backup.

Using existing backups as a baseline for new backups to reduce backup creation time

Existing backups of a file share within a region are used as baselines for creating new backups of the file share, reducing backup creation time. Therefore, we recommend that you do the following:

  • Take a new backup of a file share before you delete the previous backup of that file share.
  • Wait for new backups to be in the Ready state before creating subsequent backups of the same file share.

Scheduling backups during off-peak hours to reduce backup creation time

Creating backups during off-peak hours reduces the time that it takes to create a backup. If you schedule regular backups of your file shares, we recommend scheduling them during off-peak hours when possible.

Peak hours for backups creation are the end of each business day and midnight in the region where the Filestore instance is located. We recommend creating your backups either in the early morning or during the business day.

Organizing your data on separate Filestore instances to maximize efficiency

A backup copies all file data and metadata on a file share. The more data on the file share, the larger the backup and the more it costs. To back up only the data that you need to back up, we recommend organizing your data on separate file shares, namely:

  • Storing critical data with different write patterns or with different backup requirements on different file shares.
  • Reducing the number of backups that you need to create by keeping similar data in one file share.

What's next