mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-28 15:38:33 +02:00
Merge pull request #569 from qdrant/mjang-aws-backup
- Set up process for AWS backups - Goal: system that works with GCP backups
This commit is contained in:
Mike Jang
@@ -39,4 +39,4 @@ Now that you have signed up via AWS Marketplace, please read our instructions to
|
||||
|
||||
2. Learn how to [authenticate and access your cluster](../../cloud/authentication/).
|
||||
|
||||
3. Additional open source [documentation](../../troubleshooting/).
|
||||
3. Additional open source [documentation](../../troubleshooting/).
|
||||
|
||||
@@ -1,36 +1,95 @@
|
||||
---
|
||||
title: Backups
|
||||
weight: 30
|
||||
weight: 60
|
||||
---
|
||||
|
||||
# Backups
|
||||
# Cloud Backups
|
||||
|
||||
There are situations where you need to restore your cluster because of application or system failure.
|
||||
In most cases you will have a source of truth for your data in a regular database and would be able to reindex the data into your Qdrant vector search cluster.
|
||||
However, encoding and uploading a big amount of data might require a long time.
|
||||
For high availability critical projects we highly recommend relying on replication, which is always a better option, because it guarantees the proper cluster functionality as long as at least one replica is running.
|
||||
For less critical use-cases you can make use of one of the available options.
|
||||
Qdrant organizes cloud instances as clusters. On occasion, you may need to
|
||||
restore your cluster because of application or system failure.
|
||||
|
||||
You may already have a source of truth for your data in a regular database. If you
|
||||
have a problem, you could reindex the data into your Qdrant vector search cluster.
|
||||
However, this process can take time. For high availability critical projects we
|
||||
recommend replication. It guarantees the proper cluster functionality as long as
|
||||
at least one replica is running.
|
||||
|
||||
For less critical use-cases you can set up automatic or self-service backups.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You can back up your Qdrant clusters though the Qdrant Cloud
|
||||
Dashboard at https://cloud.qdrant.io. This section assumes that you've already
|
||||
set up your cluster, as described in the following sections:
|
||||
|
||||
- [Create a cluster](/documentation/cloud/create-cluster/)
|
||||
- Set up [Authentication](/documentation/cloud/authentication/)
|
||||
- Configure one or more [Collections](/documentation/concepts/collections/)
|
||||
|
||||
## Automatic backups
|
||||
|
||||
The cloud platform offers an option for automatic backups of your clusters. It is possible to configure periodical file system level snapshots to restore a cluster from a hard copy.
|
||||
On the cluster settings section you can choose how often a backup should be taken and how many copies you want to keep.
|
||||
You can set up automatic backups of your clusters with our Cloud UI at
|
||||
https://cloud.qdrant.io. With the procedures listed in this page, you can set up
|
||||
snapshots on a daily/weekly/monthly basis. You can keep as many snapshots as you
|
||||
need. You can restore a cluster from the snapshot of your choice.
|
||||
|
||||
To restore a Qdrant cluster from backup, you can select a desired backup copy version and start the restore process.
|
||||
Attention: during the restoring process the affected cluster will not be available because the cluster will be deleted and created from scratch from the backup copy.
|
||||
Please also note, that if you changed the cluster setup after the copy was created, the new cluster will reset to the previous configuration.
|
||||
> Note: Restoring a snapshot may create issues:
|
||||
> - The affected cluster is not available while a snapshot is being restored.
|
||||
> - If you changed the cluster setup after the copy was created, the new cluster
|
||||
resets to the previous configuration. You may lose data after the date of
|
||||
that restored snapshot.
|
||||
|
||||
## Self-service backups
|
||||
### Configure a backup
|
||||
|
||||
Qdrant engine offers a snapshot API that allows to create a snapshot of a particular collection or even the whole storage.
|
||||
Please refer to the [snapshot documentation](../../concepts/snapshots/) for details.
|
||||
After you have taken the prerequisite steps, you can configure a backup with the
|
||||
[Qdrant Cloud Dashboard](https://cloud.qdrant.io). To do so, take these steps:
|
||||
|
||||
Here is how you can quickly snapshot and recover a collection:
|
||||
1. Sign in to the dashboard
|
||||
1. Select Clusters.
|
||||
1. Select the cluster that you want to back up.
|
||||
|
||||
1. Find and select the **Backups** tab.
|
||||
1. Now you can set up a backup schedule.
|
||||
The **Days of Retention** is the number of days after a backup snapshot is
|
||||
deleted.
|
||||
1. Alternatively, you can select **Backup now** to take an immediate snapshot.
|
||||
|
||||
1. Take a snapshot
|
||||
- In case of a single node cluster, simply call the snapshot endpoint on the exposed url.
|
||||
- In case of a multi node cluster you’d need to take a snapshot on each node that the collection resides upon. To achieve this, you simply prepend `node-{num}-` to your cluster url and call the [snapshot endpoint](../../concepts/snapshots/#create-snapshot) on the individual hosts, starting with node 0 up to the number of nodes minus one.
|
||||
- In the response you'll get the name of the snapshot taken.
|
||||
|
||||
|
||||
### Restore a backup
|
||||
|
||||
If you have a backup, it appears in the list of **Available Backups**. You can
|
||||
choose to restore or delete the backups of your choice.
|
||||
|
||||
|
||||
|
||||
<!-- I think we should move this to the Snapshot page, but I'll do it later -->
|
||||
|
||||
## Backups with a snapshot
|
||||
|
||||
Qdrant also offers a snapshot API which allows you to create a snapshot
|
||||
of a specific collection or your entire cluster. For more information, see our
|
||||
[snapshot documentation](/documentation/concepts/snapshots/).
|
||||
|
||||
Here is how you can snapshot and recover a collection:
|
||||
|
||||
1. Take a snapshot:
|
||||
- For a single node cluster, call the snapshot endpoint on the exposed URL.
|
||||
- For a multi node cluster call a snapshot on each node of the collection.
|
||||
Specifically, prepend `node-{num}-` to your cluster URL.
|
||||
Then call the [snapshot endpoint](../../concepts/snapshots/#create-snapshot) on the individual hosts. Start with node 0.
|
||||
- In the response, you'll see the name of the snapshot.
|
||||
2. Delete and recreate the collection.
|
||||
3. Recover the snapshot
|
||||
- Call the [recover endpoint](../../concepts/snapshots/#recover-in-cluster-deployment) with location pointing to the snapshot file (`file:///qdrant/snapshots/{collection_name}/{snapshot_file_name}`) you got for each host.
|
||||
3. Recover the snapshot:
|
||||
- Call the [recover endpoint](../../concepts/snapshots/#recover-in-cluster-deployment). Set a location which points to the snapshot file (`file:///qdrant/snapshots/{collection_name}/{snapshot_file_name}`) for each host.
|
||||
|
||||
## Backup considerations
|
||||
|
||||
Backups are incremental. For example, if you have two backups, backup number 2
|
||||
contains only the data that changed since backup number 1. This reduces the
|
||||
total cost of your backups.
|
||||
|
||||
You can create multiple backup schedules.
|
||||
|
||||
When you restore a snapshot, any changes made after the date of the snapshot
|
||||
are lost.
|
||||
|
||||
Reference in New Issue
Block a user