Describe the bug
Snapshot registration API has a parameter shard_path_type which determines how the blobs will be created in the storage service.
POST /_snapshot/<repository>/
PUT /_snapshot/<repository>/
parameter shard_path_type is set to HASHED_PREFIX by default
This is a major change as it causes to upload the blobs outside base_path in storage services like S3/MinIO
Related component
Storage:Snapshots
To Reproduce
- Install OpenSearch 3.5.0
- Register a Snapshot registry
PUT /_snapshot/<repository>/ with default values
- Take snapshot
- Verify blobs getting created outside base path in S3/MinIO
- Set the param
shard_path_type to FIXED and register repository again.
- Take a snapshot
- Now verify the storage service, the blobs will be created inside base_path (which is the default expected behavior)### Expected behavior
Until OpenSearch Version 2.x, the blobs were created inside the base path but now since the default value of shard_path_type is changed to HASHED_PREFIX, we are observing this new behavior which really affects when someone is upgrading from version 2.x to 3.x.
This cause failure in incremental backup for indices from 2.x to 3.x after performing an upgrade.
Additional Details
Plugins
s3-repository-plugin
Screenshots

Host/Environment (please complete the following information):
- OS: Rocky 8 Linux
- Version: 3.5.0
Additional context
We wanted to understand the reason for change in this behavior.
Describe the bug
Snapshot registration API has a parameter
shard_path_typewhich determines how the blobs will be created in the storage service.parameter
shard_path_typeis set toHASHED_PREFIXby defaultThis is a major change as it causes to upload the blobs outside base_path in storage services like S3/MinIO
Related component
Storage:Snapshots
To Reproduce
PUT /_snapshot/<repository>/with default valuesshard_path_typetoFIXEDand register repository again.Until OpenSearch Version 2.x, the blobs were created inside the base path but now since the default value of
shard_path_typeis changed toHASHED_PREFIX, we are observing this new behavior which really affects when someone is upgrading from version 2.x to 3.x.This cause failure in incremental backup for indices from 2.x to 3.x after performing an upgrade.
Additional Details
Plugins
s3-repository-plugin
Screenshots

Host/Environment (please complete the following information):
Additional context
We wanted to understand the reason for change in this behavior.