From 4952ea4472481ba1762dea564f480ba58eb3ad64 Mon Sep 17 00:00:00 2001
From: evgiz
- This guide documents how to export data from a Vespa cloud application and how to do mass updates or removals.
- See cloning applications and data
- for how to copy documents from one application to another.
+ This guide covers data management operations for Vespa Cloud applications,
+ including automated backups, document export, feed, and bulk updates and removals.
- Prerequisite: Use the latest version of the vespa
- command-line client.
+ On commercial and enterprise plans, content clusters are automatically backed up when a
+
+ If you prefer to manage backups yourself, documents can be exported manually using
+
To export documents, configure the application to export from,
then select zone, container cluster and schema - example:
@@ -45,21 +61,9 @@ Automated Backups
<backup> element is specified in deployment.xml.
+ Vespa Cloud manages the backup schedule, storage, and lifecycle with no external tooling required. Backups will run at the configured frequency
+ while also respecting any block windows defined for the instance.
+{% highlight xml %}
+
+vespa visit as shown in the
+ Google Cloud Function example.
Export documents
+{% include note.html content='The examples below use the Vespa CLI. Ensure you have the latest version installed.' %}
Export documents
Note that this normally does not speed up the exporting process, as the same amount of data is read from the index.
The data transfer out of the Vespa application is smaller with fewer fields.
- Use the visit operations above to extract documents for backup. -
- To back up documents to your own Google Cloud Storage, see - - backup for a Google Cloud Function example. +For copying documents between applications, see cloning applications and data.
- - -
diff --git a/en/reference/applications/deployment.html b/en/reference/applications/deployment.html
index 1f7dbb5fb0..28e693ed10 100644
--- a/en/reference/applications/deployment.html
+++ b/en/reference/applications/deployment.html
@@ -40,6 +40,7 @@
days="mon,wed-fri"
hours="16-23"
time-zone="UTC" />
+
+In
+ Backup activity does not affect service availability, but has costs in terms of performance. You can use block-change
+backup
+<deployment>, or <instance>.
+Configures scheduled backups of production content clusters. When present, backups will
+be created at the specified frequency. Must be placed after any <test> and <staging> tags,
+and before <prod>.
+
+
+
+
+
+
+
+ Attribute
+ Mandatory
+ Values
+
+
+ frequency
+ Yes
+ A positive integer with a suffix
+ h (hours) or d (days),
+ e.g. 12h or 7d. Minimum 1h.
+
+
+granularity
+ No, default
+ cluster
+
+
+
+ cluster: all content nodes in the clustergroup: all content nodes in a single groupgranularity
+ to control the tradeoff between backup and restoration speed.
+
+
+ cluster backup will take longer,
+ as each content node must be temporarily suspended to ensure data integrity. Restoration will however require
+ effectively zero content redistribution.
+ group backup will be faster, as an entire group will be suspended and backed up simultaneously.
+ Restoration may however require a significant amount of content redistribution, depending on the cluster topology.
+
+ In most situations we recommend cluster backups.
+
+ Block windows also prevent new backups from starting in the given period. + If the available time is too short for a full backup to complete, the process will, however, extend into the block window. +
+
In <deployment>, or <instance>.
@@ -479,7 +536,7 @@
In <deployment>.
Optionally used to control deployment settings for the dev environment.
-This can be used specify a different cloud account, tags, and private endpoints.
+This can be used specify a different cloud account, tags, and private endpoints.