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 Backing up and restoring file shares.
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. It works for Basic HDD and Basic SSD tier instances. 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 completely 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 the user specifies 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 GCP region, but they cannot be shared across projects.
Backups within a region are created incrementally based on previous backups. This means that the first backup you create is a complete copy of the file share, but subsequent backups include only the new or modified data that is 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:
|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 is 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.
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
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 in the event of a disaster involving this region. You
can schedule a job
that regularly creates backups of this instance to a remote region, say
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 the data in a Filestore instance against unintended changes, you can schedule a job that regularly creates backups of the instance within the same region as the instance. In the event of data loss, you can browse through the list of backups to identify the one with the version of the file needed, create a new Filestore instance from the backup, mount it to the same client as the original instance, and then 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 will be lost.
Creating clones for development and testing
Imagine you have a database setup 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.
Once you create a Filestore instance, you cannot change its location or service tier. If you need to migrate your data to another region, you can create a backup of it and use the backup to create a new Filestore instance in the region that you want or restore it to an existing instance.
Additionally, 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.
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
When you create a backup of a file share in a region with existing backups of that file share, the existing backups are used as baselines for creating the new backup. This means that the system can create a new backup faster than if there is no existing backups. 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
Readystate 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 backup only the data that you need to back up, we recommend organizing your data on separate file shares. This includes:
- 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.
- Learn how to backup and restore file shares.
- Learn how to schedule backups using Cloud Scheduler.
- Learn about Google Cloud regions and zones.
- Learn about backups pricing.