krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-09-30 16:38:31 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated backups copy

Browse Source
This commit is contained in:
Fabrizio Bonavita
2023-11-07 12:39:09 +01:00
parent 575fb13200
commit ec319b33db
1 changed files with 9 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/documentation/cloud/backups.md
+9 -12
View File
@@ -11,6 +11,15 @@ 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 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. For less critical use-cases you can make use of one of the available options.
## 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.
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.
## Self-service backups ## Self-service backups
Qdrant engine offers a snapshot API that allows to create a snapshot of a particular collection or even the whole storage. Qdrant engine offers a snapshot API that allows to create a snapshot of a particular collection or even the whole storage.
@@ -25,15 +34,3 @@ Here is how you can quickly snapshot and recover a collection:
2. Delete and recreate the collection. 2. Delete and recreate the collection.
3. Recover the snapshot 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. - 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
We are currently offering this service on a request-only basis. Please [**let us know**](mailto:cloud@qdrant.io) if you would like to activate automatic backups.
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.