# Manage Snap-To-Object using the CLI

Using the CLI, you can:

* [Upload a snapshot](#upload-a-snapshot)
* [Create a filesystem from an uploaded snapshot](#create-a-filesystem-from-an-uploaded-snapshot)
* [Manage synchronous snapshots](#manage-synchronous-snapshots)
* [Recover a filesystem from a remote snapshot](#recover-a-filesystem-from-a-remote-snapshot)

## Upload a snapshot

**Command:** `weka fs snapshot upload`

Use the following command line to upload an existing snapshot:

`weka fs snapshot upload <file-system> <snapshot> [--site site]`

**Parameters**

<table><thead><tr><th width="186.33333333333331">Name</th><th>Value</th><th>Default</th></tr></thead><tbody><tr><td><code>file-system</code>*</td><td>Name of the filesystem</td><td></td></tr><tr><td><code>snapshot</code>*</td><td>Name of the snapshot of the <code>&#x3C;file-system></code> filesystem to upload.<br></td><td></td></tr><tr><td><code>site</code>*</td><td>Location for the snapshot upload.<br>Mandatory only if both <code>local</code> and <code>remote</code> buckets are attached.<br>Possible values: <code>local</code> or <code>remote</code></td><td>Auto-selected if only one bucket for upload is attached.</td></tr></tbody></table>

## Create a filesystem from an uploaded snapshot

**Command:** `weka fs download`

Use the following command to create or recreate a filesystem from an existing snapshot. If the snapshot originates from an encrypted source, be sure to include the required KMS-related parameters:

`weka fs download <name> <group-name> <total-capacity> <ssd-capacity> <obs-bucket> <locator>` \[--auth-required auth-required] `[--additional-obs additional-obs] [--snapshot-name snapshot-name] [--access-point access-point] [--kms-key-identifier kms-key-identifier] [--kms-namespace kms-namespace] [--kms-role-id kms-role-id] [--kms-secret-id kms-secret-id] [--skip-resource-validation]`

When creating a filesystem from a snapshot, a background cluster task automatically prefetches its metadata, providing better latency for metadata queries.

**Parameters**

<table><thead><tr><th width="229">Name</th><th width="332">Value</th><th>Default</th></tr></thead><tbody><tr><td><code>name</code>*</td><td>Name of the filesystem to create.</td><td></td></tr><tr><td><code>group-name</code>*</td><td>Name of the filesystem group in which the new filesystem is placed.</td><td></td></tr><tr><td><code>total-capacity</code>*</td><td>The total capacity of the downloaded filesystem.</td><td></td></tr><tr><td><code>ssd-capacity</code>*</td><td>SSD capacity of the downloaded filesystem.</td><td></td></tr><tr><td><code>obs-bucket</code>*</td><td>Object store name for tiering.</td><td></td></tr><tr><td><code>locator</code>*</td><td>Object store locator obtained from a previously successful snapshot upload.</td><td></td></tr><tr><td><code>auth-required</code></td><td>Require authentication for the mounting user when mounting this filesystem. This setting is only applicable in the root organization; users in non-root organizations must always be authenticated to perform a mount operation. Format: <code>yes</code> or <code>no</code>.</td><td><code>no</code></td></tr><tr><td><code>additional-obs</code></td><td>An additional object-store name.<br>If the data to recover reside in two object stores (a second object store attached to the filesystem, and the filesystem has not undergone full migration), this object store is attached in a <code>read-only</code> mode.<br>The snapshot locator must be in the primary object store specified in the <code>obs</code> parameter.</td><td></td></tr><tr><td><code>snapshot-name</code></td><td>The downloaded snapshot name.</td><td>The uploaded snapshot name.</td></tr><tr><td><code>access-point</code></td><td>The downloaded snapshot access point.</td><td>The uploaded access point.</td></tr><tr><td><code>kms-key-identifier</code></td><td>Customize KMS key name for this filesystem (applicable only for HashiCorp Vault).</td><td></td></tr><tr><td><code>kms-namespace</code></td><td>Customize the KMS role ID for this filesystem (applicable only for HashiCorp Vault).</td><td></td></tr><tr><td><code>kms-role-id</code></td><td>Customize the KMS role ID for this filesystem (applicable only for HashiCorp Vault).</td><td></td></tr><tr><td><code>kms-secret-id</code></td><td>Customize the KMS secret ID for this filesystem (applicable only for HashiCorp Vault).</td><td></td></tr><tr><td><code>skip-resource-validation</code></td><td>Skip verifying RAM and SSD resource allocation for the downloaded filesystem on the cluster.</td><td></td></tr></tbody></table>

{% hint style="info" %}
For encrypted filesystems, when downloading, you must use the same KMS cluster-wide key or, if configured, the per-filesystem encryption parameters to decrypt the snapshot data. For more information, see [Manage KMS](/security/kms-management.md).
{% endhint %}

The `locator` can be a previously saved locator for disaster scenarios, or you can obtain the `locator` using the `weka fs snapshot` command on a system with a live filesystem with snapshots.

If you need to pause and resume the download process, use the command: `weka cluster task pause / resume`. To abort the download process, delete the downloaded filesystem directly. For details, see [Background tasks](/operation-guide/background-tasks.md).

{% hint style="info" %}
Due to the bandwidth characteristics and potential costs when interacting with remote object stores it is not allowed to download a filesystem from a remote object-store bucket. If a snapshot on a local object-store bucket exists, it is advisable to use that one. Otherwise, follow the procedure in[#recover-from-a-remote-snapshot](#recover-from-a-remote-snapshot "mention").
{% endhint %}

## Manage synchronous snapshots

The workflow to manage the synchronous snapshots includes:

1. Upload snapshots using, for example, the snapshots scheduler.
2. Download the synchronous snapshot (described below).
3. Restore a specific snapshot to a filesystem. See

**Related topics**

[Snapshots](/weka-filesystems-and-object-stores/snapshots.md)

[Manage snapshots using the CLI](/weka-filesystems-and-object-stores/snapshots/snapshots-1.md#restore-a-snapshot-to-a-filesystem-or-another-snapshot)

### Download a synchronous snapshot

**Command:** `weka fs snapshot download`

Use the following command line to download a synchronous snapshot. This command is only relevant for snapshots uploaded from a system of version 4.3 and later:

`weka fs snapshot download <file-system> <locator>`

{% hint style="warning" %}
Make sure to download synchronous snapshots in chronological order. Non-chronological snapshots are inefficient and are not synchronous.

If you need to download a snapshot earlier than the latest downloaded one, for example, when you need one of the daily synchronous snapshots after the weekly synchronous snapshot was downloaded, add the `--allow-non-chronological` flag to download it anyway.
{% endhint %}

**Parameters**

<table><thead><tr><th width="304">Name</th><th>Value</th></tr></thead><tbody><tr><td><code>file-system</code>*</td><td>Name of the filesystem.</td></tr><tr><td><code>locator</code>*</td><td>Object store locator obtained from a previously successful snapshot upload.</td></tr></tbody></table>

If you need to pause and resume the download process, use the command: `weka cluster task pause / resume`. To abort the download process, delete the downloaded snapshot directly.

**Related topics**

[Snap-To-Object](/weka-filesystems-and-object-stores/snap-to-obj.md#synchronous-snapshots)

[Background tasks](/operation-guide/background-tasks.md)

## Recover a filesystem from a remote snapshot

Recover a filesystem by defining a remote object store bucket as a local bucket. This process ensures high performance and bypasses download restrictions associated with remote object stores by utilizing local Quality of Service (QoS) configurations.

**Before you begin**

* Identify the remote object store bucket name and credentials.
* Ensure the WEKA cluster has network connectivity to the remote object store.
* Verify sufficient licensing for the new filesystem capacity.

**Procedure**

1. Add a new local object store:

   ```bash
   weka fs tier obs add <name> <type> <hostname>
   ```
2. Add a local object store bucket that refers to the bucket containing the remote snapshot:

   ```bash
   weka fs tier s3 add <name> <obs-name> <bucket> <access-key> <secret-key>
   ```
3. Download the filesystem:

   ```bash
   weka fs download <fs-name> <bucket-name> <snapshot-name>
   ```
4. If the recovered filesystem requires tiering, add a local object store bucket for data storage:

   ```bash
   weka fs tier s3 add <tier-bucket-name> <obs-name> <bucket> <access-key> <secret-key>
   ```
5. Detach the initial recovery bucket from the filesystem.
6. If a remote backup is required for this filesystem, attach a remote bucket.
7. Remove the temporary local object store bucket and the local object store used for the recovery.

**Related topic**

[Manage object stores](/weka-filesystems-and-object-stores/managing-object-stores.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.weka.io/weka-filesystems-and-object-stores/snap-to-obj/snap-to-obj-1.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.