mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-26 14:38:30 +02:00
3215985d1d
* added a table of content * wide layout for docs, styles for the table of content * fixes for docs layout * wide footer at the docs section * added support for nested docs, added toggling groups of links, delimiters, external links * external link icon * added active state for nested links, styles for the external link icon * styles fix * remove doc sync * update directory structure and doc titles * fix outstanding links * fix more links for merge * Revert "fix more links for merge" This reverts commit 46c9ccaf1b7765f2cda8dc85d625fa6b4e3f5436. * Revert "fix outstanding links" This reverts commit 28e6380b74f1ab74690c8184551f186656d6d4e9. * fix remaining broken links * move how-to tutorials in the different page * split tutorials * fix link * upd github edit link * skip empty index pages --------- Co-authored-by: Andrey Vasnetsov <andrey@vasnetsov.com> Co-authored-by: David Sertic <62056091+davidmyriel@users.noreply.github.com>
42 lines
2.6 KiB
Markdown
42 lines
2.6 KiB
Markdown
---
|
||
title: Backups
|
||
weight: 20
|
||
---
|
||
|
||
# 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.
|
||
|
||
## Self-service backups
|
||
|
||
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.
|
||
|
||
A quick recipe for successfully snapshotting and recovering a collection:
|
||
|
||
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.
|
||
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.
|
||
|
||
|
||
## Automatic backups
|
||
|
||
**Note: not available in the beta version.**
|
||
|
||
Note: not available in the beta version.
|
||
The cloud platform offers an option for automatic system backups.
|
||
It is possible to configure periodical 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 done and how many latest copies should be kept on the backup storage.
|
||
To restore a Qdrant cluster from backup, you can select a desired backup copy version and start the reporting 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 topology after the copy was created, the new cluster will reset to the previous configuration.
|
||
|