S
Subhash_athreya
Azure Files is a fully managed cloud file share service that enables organizations to share data across on-premises and cloud. The service is truly cross-platform and supports mounting of file share from any client that implements SMB and NFS protocols, it also exposes REST APIs for programmability. A key part file share service offering is its integrated backup for point in time recovery, this enables recovery of data from certain periods in the past in case data is deleted or corrupted. Such capability is best offered by Snapshots.
We are excited to announce public preview of Snapshot support for NFS share. Customers using NFS shares will now be able to perform share level Snapshot management operations via REST API, PowerShell and CLI. Using Snapshots users will be able to roll back the entire filesystems or pull specific files that were accidentally deleted or corrupted. Therefore, it is always recommended to create a snapshot schedule that best suits your RPO (recovery point objective) requirement. Snapshot schedule frequency can be hourly, daily, weekly or monthly. Having such flexibility will help IT infra teams to serve a wide spectrum of RPO requirements suiting business needs.
Although there are multiple scenarios where snapshots can benefit users, I will be highlighting two important scenarios that are widely sought after.
Scenario #1 Recover files in case of accidental deletions, corruption, or user errors.
Scenario #2 Start-up read only replica of your application or database in few minutes to serve your reporting or analytics scenarios.
Scenario #1 Recovery of data during accidental deletions and corruption is the most common scenario for admins during their day-to-day operations. There are solutions like backup (creating full and incremental copies of data) that help to recover the data from such scenarios, but snapshot technology offers more frequent recovery points (Lower RPO) to restore the data unlike backups. Snapshots are also considered to be space efficient since they capture only incremental changes.
Creating snapshots of NFS file share is straightforward. This can be accomplished via Portal, REST, PowerShell or CLI. Let me show you how to access file share snapshots via NFS client to perform single file restore operations which can help you to recover data in accidental deletions or corruption scenarios.
cd into the specific snapshot to view the files to be recovered.
Scenario #2 If you have an application or a database deployed on a NFS file share, one can create crash consistent or application consistent snapshot of NFS file share. Crash consistent is offered by default but Application consistent snapshots are not built-in capability, it will require admins to run few additional steps which can quiesce and unquiesce the application during snapshot creation process.
For example, if you have a MySQL database one can write script to a execute a 3-step (quiesce(MySQL), snapshot(File share), and unquiesce(MySQL)) process to create an application-consistent snapshot of the database hosted on file share.
Quiesce and unquiesce commands varies depending on the application or the database hosted on the file share.
Such application consistent snapshots can be directly mounted on the desired NFS client and can be used as read only replicas for reporting and data analytics use-cases.
The mounted snapshots can be used by applications or databases to create read-only static copies of the production database for analytics or reporting use-cases. They can be also copied to another location and then applications can be allowed to perform changes/writes.
To improve copy performance, especially for large datasets with multiple files mount NFS snapshot using Nconnect setting which is available on latest Linux distributions and use fpsync to copy data out of snapshot to desired location. Sample scripts updated here
For more information refer to documentation
Mount an NFS Azure file share on Linux | Microsoft Learn
Snapshot Share (FileREST API) - Azure Files | Microsoft Learn
Continue reading...
We are excited to announce public preview of Snapshot support for NFS share. Customers using NFS shares will now be able to perform share level Snapshot management operations via REST API, PowerShell and CLI. Using Snapshots users will be able to roll back the entire filesystems or pull specific files that were accidentally deleted or corrupted. Therefore, it is always recommended to create a snapshot schedule that best suits your RPO (recovery point objective) requirement. Snapshot schedule frequency can be hourly, daily, weekly or monthly. Having such flexibility will help IT infra teams to serve a wide spectrum of RPO requirements suiting business needs.
Although there are multiple scenarios where snapshots can benefit users, I will be highlighting two important scenarios that are widely sought after.
Scenario #1 Recover files in case of accidental deletions, corruption, or user errors.
Scenario #2 Start-up read only replica of your application or database in few minutes to serve your reporting or analytics scenarios.
Scenario #1 Recovery of data during accidental deletions and corruption is the most common scenario for admins during their day-to-day operations. There are solutions like backup (creating full and incremental copies of data) that help to recover the data from such scenarios, but snapshot technology offers more frequent recovery points (Lower RPO) to restore the data unlike backups. Snapshots are also considered to be space efficient since they capture only incremental changes.
Creating snapshots of NFS file share is straightforward. This can be accomplished via Portal, REST, PowerShell or CLI. Let me show you how to access file share snapshots via NFS client to perform single file restore operations which can help you to recover data in accidental deletions or corruption scenarios.
- The first step is to mount the file share : cd “.snapshots” directory under root to view the snapshots that are already created. “.snapshot” directory is by default hidden but users will be able to access and read from the directory like a normal directory
- Each snapshot available/listed under .snapshot directory is a recovery point in itself.
cd into the specific snapshot to view the files to be recovered.
- Initiate copy of required files and directories from snapshot to the desired location to complete the restore using cp command.
Scenario #2 If you have an application or a database deployed on a NFS file share, one can create crash consistent or application consistent snapshot of NFS file share. Crash consistent is offered by default but Application consistent snapshots are not built-in capability, it will require admins to run few additional steps which can quiesce and unquiesce the application during snapshot creation process.
For example, if you have a MySQL database one can write script to a execute a 3-step (quiesce(MySQL), snapshot(File share), and unquiesce(MySQL)) process to create an application-consistent snapshot of the database hosted on file share.
Quiesce and unquiesce commands varies depending on the application or the database hosted on the file share.
Such application consistent snapshots can be directly mounted on the desired NFS client and can be used as read only replicas for reporting and data analytics use-cases.
The mounted snapshots can be used by applications or databases to create read-only static copies of the production database for analytics or reporting use-cases. They can be also copied to another location and then applications can be allowed to perform changes/writes.
To improve copy performance, especially for large datasets with multiple files mount NFS snapshot using Nconnect setting which is available on latest Linux distributions and use fpsync to copy data out of snapshot to desired location. Sample scripts updated here
For more information refer to documentation
Mount an NFS Azure file share on Linux | Microsoft Learn
Snapshot Share (FileREST API) - Azure Files | Microsoft Learn
Continue reading...