Share snapshots¶
The Shared File Systems service provides a snapshot mechanism to help users restore data by running the openstack share snapshot create command.
To export a snapshot, create a share from it, then mount the new share to an instance. Copy files from the attached share into the archive.
To import a snapshot, create a new share with appropriate size, attach it to instance, and then copy a file from the archive to the attached file system.
Note
You cannot delete a share while it has saved dependent snapshots.
Create a snapshot from the share:
$ openstack share snapshot create Share1 --name Snapshot1 \
--description "Snapshot of Share1"
+-------------+--------------------------------------+
| Field | Value |
+-------------+--------------------------------------+
| id | 962e8126-35c3-47bb-8c00-f0ee37f42ddd |
| share_id | aca648eb-8c03-4394-a5cc-755066b7eb66 |
| share_size | 1 |
| created_at | 2026-03-31T05:27:38.188948 |
| status | creating |
| name | Snapshot1 |
| description | Snapshot of Share1 |
| size | 1 |
| share_proto | NFS |
| user_id | 5c7bdb6eb0504d54a619acf8375c08ce |
| project_id | cadd7139bc3148b8973df097c0911016 |
| metadata | {} |
+-------------+--------------------------------------+
Update snapshot name or description if needed:
$ openstack share snapshot set Snapshot1 --name Snapshot_1 \
--description "Snapshot of Share1. Updated."
Check that status of a snapshot is available:
$ openstack share snapshot show Snapshot1
+-------------+--------------------------------------+
| Field | Value |
+-------------+--------------------------------------+
| id | 962e8126-35c3-47bb-8c00-f0ee37f42ddd |
| share_id | aca648eb-8c03-4394-a5cc-755066b7eb66 |
| share_size | 1 |
| created_at | 2026-03-31T05:27:38.188948 |
| status | available |
| name | Snapshot1 |
| description | Snapshot of Share1 |
| size | 1 |
| share_proto | NFS |
| user_id | 5c7bdb6eb0504d54a619acf8375c08ce |
| project_id | cadd7139bc3148b8973df097c0911016 |
| properties | |
+-------------+--------------------------------------+
To create a copy of your data from a snapshot, use openstack share create
with key --snapshot-id. This creates a new share from an
existing snapshot. Create a share from a snapshot and check whether it is
available:
$ openstack share create nfs 1 --name Share2 --property source=snapshot \
--description "Share from a snapshot." \
--snapshot-id 962e8126-35c3-47bb-8c00-f0ee37f42ddd
+---------------------------------------+--------------------------------------+
| Field | Value |
+---------------------------------------+--------------------------------------+
| id | b6b0617c-ea51-4450-848e-e7cff69238c7 |
| size | 1 |
| availability_zone | nova |
| created_at | 2026-03-31T06:25:50.309282 |
| status | creating |
| name | Share2 |
| description | Share from a snapshot. |
| project_id | 20787a7ba11946adad976463b57d8a2f |
| snapshot_id | 962e8126-35c3-47bb-8c00-f0ee37f42ddd |
| share_network_id | None |
| share_proto | NFS |
| metadata | {'source': 'snapshot'} |
| share_type | c0086582-30a6-4060-b096-a42ec9d66b86 |
| is_public | False |
| snapshot_support | True |
| task_state | None |
| share_type_name | default |
| access_rules_status | active |
| replication_type | None |
| has_replicas | False |
| user_id | 5c7bdb6eb0504d54a619acf8375c08ce |
| create_share_from_snapshot_support | True |
| revert_to_snapshot_support | True |
| share_group_id | None |
| source_share_group_snapshot_member_id | None |
| mount_snapshot_support | True |
| progress | None |
+---------------------------------------+--------------------------------------+
$ openstack share show Share2
+---------------------------------------+---------------------------------------------------------------+
| Field | Value |
+---------------------------------------+---------------------------------------------------------------+
| id | b6b0617c-ea51-4450-848e-e7cff69238c7 |
| size | 1 |
| availability_zone | nova |
| created_at | 2026-03-31T06:25:50.309282 |
| status | available |
| name | Share2 |
| description | Share from a snapshot. |
| project_id | 20787a7ba11946adad976463b57d8a2f |
| snapshot_id | 962e8126-35c3-47bb-8c00-f0ee37f42ddd |
| share_network_id | None |
| share_proto | NFS |
| share_type | c0086582-30a6-4060-b096-a42ec9d66b86 |
| is_public | False |
| snapshot_support | True |
| task_state | None |
| share_type_name | default |
| access_rules_status | active |
| replication_type | None |
| has_replicas | False |
| user_id | 5c7bdb6eb0504d54a619acf8375c08ce |
| create_share_from_snapshot_support | True |
| revert_to_snapshot_support | True |
| share_group_id | None |
| source_share_group_snapshot_member_id | None |
| mount_snapshot_support | True |
| progress | 100% |
| export_locations | |
| | id = 33d0964d-a968-40d5-97c4-b9371f580e46 |
| | path = 203.0.113.3:/shares/share-1dc2a471-3d47-4e1a-bf6c-bd01 |
| | preferred = True |
| properties | source='snapshot' |
+---------------------------------------+---------------------------------------------------------------+
By default, the Shared File Systems service will place the new share in the
source share’s pool, unless a different destination availability zone is
provided by the user, using the key --availability-zone.
Starting from Ussuri release, a new filter and weigher were added to the
scheduler to enhance the selection of a destination pool when creating shares
from snapshot. Drivers that support creating shares from snapshots across back
ends also need the back end configuration option replication_domain to be
specified. This option can be an arbitrary string. As an administrator, you are
expected to determine which back ends are compatible to copy data between each
other. Once you have identified these back ends, configure
replication_domain in their respective configuration sections to the same
string. Refer to the
feature support mapping
for identifying which back ends support this feature. The use of scheduler when
creating share from a snapshot must be enabled using the configuration flag
[DEFAULT]/use_scheduler_creating_share_from_snapshot. This option is
disabled by default.
Note
When combining both --snapshot-id and --availability-zone keys,
you’ll need to make sure that the configuration flag
[DEFAULT]/use_scheduler_creating_share_from_snapshot is enabled, or the
operation will be denied when source and destination availability zones are
different.
You can soft-delete a snapshot using openstack share snapshot delete
<snapshot_name_or_ID>. If a snapshot is in busy state, and during
the delete an error_deleting status appeared, administrator can
force-delete it or explicitly reset the state.
Use openstack share snapshot set <snapshot> --status <status> to update
the state of a snapshot explicitly. A valid value of a status are
available, error, creating, deleting, error_deleting.
If no status is provided, the available status will be used.
Use openstack share snapshot delete --force <snapshot> to force-delete a specified share snapshot in any state.
