mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-09-20 06:54:32 +00:00
update docs to match style guide (#2861)
* update docs to match style guide Signed-off-by: Abigail McCarthy <mabigail@vmware.com> * update web site guide Signed-off-by: Abigail McCarthy <mabigail@vmware.com>
This commit is contained in:
Abigail McCarthy
@@ -3,7 +3,7 @@ layout: docs
|
||||
title: API types
|
||||
---
|
||||
|
||||
Here we list the API types that have some functionality that you can only configure via json/yaml vs the `velero` cli
|
||||
Here's a list the API types that have some functionality that you can only configure via json/yaml vs the `velero` cli
|
||||
(hooks)
|
||||
|
||||
* [Backup][1]
|
||||
|
||||
@@ -5,7 +5,7 @@ layout: docs
|
||||
|
||||
## Use
|
||||
|
||||
The `Backup` API type is used as a request for the Velero server to perform a backup. Once created, the
|
||||
Use the `Backup` API type to request the Velero server to perform a backup. Once created, the
|
||||
Velero Server immediately starts the backup process.
|
||||
|
||||
## API GroupVersion
|
||||
@@ -36,11 +36,11 @@ spec:
|
||||
# Array of namespaces to exclude from the backup. Optional.
|
||||
excludedNamespaces:
|
||||
- some-namespace
|
||||
# Array of resources to include in the backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to include in the backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. If unspecified, all resources are included. Optional.
|
||||
includedResources:
|
||||
- '*'
|
||||
# Array of resources to exclude from the backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to exclude from the backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. Optional.
|
||||
excludedResources:
|
||||
- storageclasses.storage.k8s.io
|
||||
@@ -69,13 +69,13 @@ spec:
|
||||
volumeSnapshotLocations:
|
||||
- aws-primary
|
||||
- gcp-primary
|
||||
# The amount of time before this backup is eligible for garbage collection. If not specified,
|
||||
# The amount of time before this backup is eligible for garbage collection. If not specified,
|
||||
# a default value of 30 days will be used. The default can be configured on the velero server
|
||||
# by passing the flag --default-backup-ttl.
|
||||
# by passing the flag --default-backup-ttl.
|
||||
ttl: 24h0m0s
|
||||
# Whether restic should be used to take a backup of all pod volumes by default.
|
||||
defaultVolumesToRestic: true
|
||||
# Actions to perform at different times during a backup. The only hook currently supported is
|
||||
# Actions to perform at different times during a backup. The only hook supported is
|
||||
# executing a command in a container in a pod using the pod exec API. Optional.
|
||||
hooks:
|
||||
# Array of hooks that are applicable to specific resources. Optional.
|
||||
@@ -101,9 +101,9 @@ spec:
|
||||
matchLabels:
|
||||
app: velero
|
||||
component: server
|
||||
# An array of hooks to run before executing custom actions. Currently only "exec" hooks are supported.
|
||||
# An array of hooks to run before executing custom actions. Only "exec" hooks are supported.
|
||||
pre:
|
||||
-
|
||||
-
|
||||
# The type of hook. This must be "exec".
|
||||
exec:
|
||||
# The name of the container where the command will be executed. If unspecified, the
|
||||
@@ -119,12 +119,12 @@ spec:
|
||||
# How long to wait for the command to finish executing. Defaults to 30 seconds. Optional.
|
||||
timeout: 10s
|
||||
# An array of hooks to run after all custom actions and additional items have been
|
||||
# processed. Currently only "exec" hooks are supported.
|
||||
# processed. Only "exec" hooks are supported.
|
||||
post:
|
||||
# Same content as pre above.
|
||||
# Status about the Backup. Users should not set any data here.
|
||||
status:
|
||||
# The version of this Backup. The only version currently supported is 1.
|
||||
# The version of this Backup. The only version supported is 1.
|
||||
version: 1
|
||||
# The date and time when the Backup is eligible for garbage collection.
|
||||
expiration: null
|
||||
@@ -144,5 +144,5 @@ status:
|
||||
warnings: 2
|
||||
# Number of errors that were logged by the backup.
|
||||
errors: 0
|
||||
|
||||
|
||||
```
|
||||
|
||||
@@ -38,11 +38,11 @@ spec:
|
||||
# Array of namespaces to exclude from the restore. Optional.
|
||||
excludedNamespaces:
|
||||
- some-namespace
|
||||
# Array of resources to include in the restore. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to include in the restore. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. If unspecified, all resources are included. Optional.
|
||||
includedResources:
|
||||
- '*'
|
||||
# Array of resources to exclude from the restore. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to exclude from the restore. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. Optional.
|
||||
excludedResources:
|
||||
- storageclasses.storage.k8s.io
|
||||
|
||||
@@ -6,7 +6,7 @@ layout: docs
|
||||
## Use
|
||||
|
||||
The `Schedule` API type is used as a repeatable request for the Velero server to perform a backup for a given cron notation. Once created, the
|
||||
Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup
|
||||
Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup
|
||||
process on a repeating basis.
|
||||
|
||||
## API GroupVersion
|
||||
@@ -41,11 +41,11 @@ spec:
|
||||
# Array of namespaces to exclude from the scheduled backup. Optional.
|
||||
excludedNamespaces:
|
||||
- some-namespace
|
||||
# Array of resources to include in the scheduled backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to include in the scheduled backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. If unspecified, all resources are included. Optional.
|
||||
includedResources:
|
||||
- '*'
|
||||
# Array of resources to exclude from the scheduled backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to exclude from the scheduled backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. Optional.
|
||||
excludedResources:
|
||||
- storageclasses.storage.k8s.io
|
||||
@@ -74,11 +74,11 @@ spec:
|
||||
volumeSnapshotLocations:
|
||||
- aws-primary
|
||||
- gcp-primary
|
||||
# The amount of time before backups created on this schedule are eligible for garbage collection. If not specified,
|
||||
# The amount of time before backups created on this schedule are eligible for garbage collection. If not specified,
|
||||
# a default value of 30 days will be used. The default can be configured on the velero server
|
||||
# by passing the flag --default-backup-ttl.
|
||||
# by passing the flag --default-backup-ttl.
|
||||
ttl: 24h0m0s
|
||||
# Actions to perform at different times during a backup. The only hook currently supported is
|
||||
# Actions to perform at different times during a backup. The only hook supported is
|
||||
# executing a command in a container in a pod using the pod exec API. Optional.
|
||||
hooks:
|
||||
# Array of hooks that are applicable to specific resources. Optional.
|
||||
@@ -104,9 +104,9 @@ spec:
|
||||
matchLabels:
|
||||
app: velero
|
||||
component: server
|
||||
# An array of hooks to run before executing custom actions. Currently only "exec" hooks are supported.
|
||||
# An array of hooks to run before executing custom actions. Only "exec" hooks are supported.
|
||||
pre:
|
||||
-
|
||||
-
|
||||
# The type of hook. This must be "exec".
|
||||
exec:
|
||||
# The name of the container where the command will be executed. If unspecified, the
|
||||
@@ -122,7 +122,7 @@ spec:
|
||||
# How long to wait for the command to finish executing. Defaults to 30 seconds. Optional.
|
||||
timeout: 10s
|
||||
# An array of hooks to run after all custom actions and additional items have been
|
||||
# processed. Currently only "exec" hooks are supported.
|
||||
# processed. Only "exec" hooks are supported.
|
||||
post:
|
||||
# Same content as pre above.
|
||||
status:
|
||||
|
||||
@@ -22,7 +22,7 @@ Refer [this document](customize-installation.md) to customize your installation.
|
||||
|
||||
Velero uses object storage to store backups and associated artifacts. It also optionally integrates with supported block storage systems to snapshot your persistent volumes. Before beginning the installation process, you should identify the object storage provider and optional block storage provider(s) you'll be using from the list of [compatible providers][0].
|
||||
|
||||
There are supported storage providers for both cloud-provider environments and on-premises environments. For more details on on-premises scenarios, see the [on-premises documentation][2].
|
||||
Velero supports storage providers for both cloud-provider environments and on-premises environments. For more details on on-premises scenarios, see the [on-premises documentation][2].
|
||||
|
||||
### Velero on Windows
|
||||
|
||||
@@ -49,7 +49,7 @@ brew install velero
|
||||
tar -xvf <RELEASE-TARBALL-NAME>.tar.gz
|
||||
```
|
||||
|
||||
1. Move the extracted `velero` binary to somewhere in your `$PATH` (e.g. `/usr/local/bin` for most users).
|
||||
1. Move the extracted `velero` binary to somewhere in your `$PATH` (`/usr/local/bin` for most users).
|
||||
|
||||
### Option 3: Windows - Chocolatey
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ Note that the Makefile targets assume building from a git repository. When build
|
||||
|
||||
There are a number of different ways to build `velero` depending on your needs. This section outlines the main possibilities.
|
||||
|
||||
When building by using `make`, it will place the binaries under `_output/bin/$GOOS/$GOARCH`. For example, you will find the binary for darwin here: `_output/bin/darwin/amd64/velero`, and the binary for linux here: `_output/bin/linux/amd64/velero`. `make` will also splice version and git commit information in so that `velero version` displays proper output.
|
||||
When building by using `make`, it will place the binaries under `_output/bin/$GOOS/$GOARCH`. For example, you will find the binary for darwin here: `_output/bin/darwin/amd64/velero`, and the binary for linux here: `_output/bin/linux/amd64/velero`. `make` will also splice version and git commit information in so that `velero version` displays proper output.
|
||||
|
||||
Note: `velero install` will also use the version information to determine which tagged image to deploy. If you would like to overwrite what image gets deployed, use the `image` flag (see below for instructions on how to build images).
|
||||
|
||||
@@ -101,7 +101,7 @@ _Note: To build build container images for both `velero` and `velero-restic-rest
|
||||
|
||||
### Cross platform building
|
||||
|
||||
Docker `buildx` platforms currently supported:
|
||||
Docker `buildx` platforms supported:
|
||||
* `linux/amd64`
|
||||
* `linux/arm64`
|
||||
* `linux/arm/v7`
|
||||
|
||||
@@ -26,7 +26,7 @@ of the Velero repository is under active development and is not guaranteed to be
|
||||
tar -xvf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to
|
||||
```
|
||||
|
||||
We'll refer to the directory you extracted to as the "Velero directory" in subsequent steps.
|
||||
The directory you extracted is called the "Velero directory" in subsequent steps.
|
||||
|
||||
1. Move the `velero` binary from the Velero directory to somewhere in your PATH.
|
||||
|
||||
@@ -44,7 +44,7 @@ Several comments:
|
||||
|
||||
2. Velero uses an AWS S3 compatible API. Which means it authenticates using a signature created from a pair of access and secret keys — a set of HMAC credentials. You can create these HMAC credentials by specifying `{“HMAC”:true}` as an optional inline parameter. See step 3 in the [Service credentials][3] guide.
|
||||
|
||||
3. After successfully creating a Service credential, you can view the JSON definition of the credential. Under the `cos_hmac_keys` entry there are `access_key_id` and `secret_access_key`. We will use them in the next step.
|
||||
3. After successfully creating a Service credential, you can view the JSON definition of the credential. Under the `cos_hmac_keys` entry there are `access_key_id` and `secret_access_key`. Use them in the next step.
|
||||
|
||||
4. Create a Velero-specific credentials file (`credentials-velero`) in your local directory:
|
||||
|
||||
@@ -54,7 +54,7 @@ Several comments:
|
||||
aws_secret_access_key=<SECRET_ACCESS_KEY>
|
||||
```
|
||||
|
||||
where the access key id and secret are the values that we got above.
|
||||
Where the access key id and secret are the values that you got above.
|
||||
|
||||
## Install and start Velero
|
||||
|
||||
@@ -69,7 +69,7 @@ velero install \
|
||||
--backup-location-config region=<YOUR_REGION>,s3ForcePathStyle="true",s3Url=<YOUR_URL_ACCESS_POINT>
|
||||
```
|
||||
|
||||
Velero does not currently have a volume snapshot plugin for IBM Cloud, so creating volume snapshots is disabled.
|
||||
Velero does not have a volume snapshot plugin for IBM Cloud, so creating volume snapshots is disabled.
|
||||
|
||||
Additionally, you can specify `--use-restic` to enable [restic support][16], and `--wait` to wait for the deployment to be ready.
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ of the Velero repository is under active development and is not guaranteed to be
|
||||
tar -xvf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to
|
||||
```
|
||||
|
||||
We'll refer to the directory you extracted to as the "Velero directory" in subsequent steps.
|
||||
The directory you extracted is called the "Velero directory" in subsequent steps.
|
||||
|
||||
1. Move the `velero` binary from the Velero directory to somewhere in your PATH.
|
||||
|
||||
@@ -71,7 +71,7 @@ These instructions start the Velero server and a Minio instance that is accessib
|
||||
--secret-file ./credentials-velero \
|
||||
--use-volume-snapshots=false \
|
||||
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.velero.svc:9000 \
|
||||
--snapshot-location-config region="default"
|
||||
--snapshot-location-config region="default"
|
||||
```
|
||||
|
||||
This example assumes that it is running within a local cluster without a volume provider capable of snapshots, so no `VolumeSnapshotLocation` is created (`--use-volume-snapshots=false`).
|
||||
@@ -237,7 +237,7 @@ You must also get the Minio URL, which you can then specify as the value of the
|
||||
|
||||
If you're using Minio with HTTPS, you may see unintelligible text in the output of `velero describe`, or `velero logs` commands.
|
||||
|
||||
In order to fix this, you can add a public URL to the `BackupStorageLocation`.
|
||||
To fix this, you can add a public URL to the `BackupStorageLocation`.
|
||||
|
||||
In a terminal, run the following:
|
||||
|
||||
@@ -249,7 +249,7 @@ If your certificate is self-signed, see the [documentation on self-signed certif
|
||||
|
||||
## Expose Minio outside your cluster with Kubernetes in Docker (KinD):
|
||||
|
||||
Kubernetes in Docker currently does not have support for NodePort services (see [this issue](https://github.com/kubernetes-sigs/kind/issues/99)). In this case, you can use a port forward to access the Minio bucket.
|
||||
Kubernetes in Docker does not have support for NodePort services (see [this issue](https://github.com/kubernetes-sigs/kind/issues/99)). In this case, you can use a port forward to access the Minio bucket.
|
||||
|
||||
In a terminal, run the following:
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ layout: docs
|
||||
|
||||
## Introduction
|
||||
|
||||
[Velero](https://velero.io/) is a tool used to backup and migrate Kubernetes applications. Here are the steps to use [Oracle Cloud Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Concepts/objectstorageoverview.htm) as a destination for Velero backups.
|
||||
[Velero](https://velero.io/) is a tool used to backup and migrate Kubernetes applications. Here are the steps to use [Oracle Cloud Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Concepts/objectstorageoverview.htm) as a destination for Velero backups.
|
||||
|
||||
1. [Download Velero](#download-velero)
|
||||
2. [Create A Customer Secret Key](#create-a-customer-secret-key)
|
||||
@@ -17,17 +17,17 @@ layout: docs
|
||||
|
||||
## Download Velero
|
||||
|
||||
1. Download the [latest release](https://github.com/vmware-tanzu/velero/releases/) of Velero to your development environment. This includes the `velero` CLI utility and example Kubernetes manifest files. For example:
|
||||
1. Download the [latest release](https://github.com/vmware-tanzu/velero/releases/) of Velero to your development environment. This includes the `velero` CLI utility and example Kubernetes manifest files. For example:
|
||||
|
||||
```
|
||||
wget https://github.com/vmware-tanzu/velero/releases/download/v1.0.0/velero-v1.0.0-linux-amd64.tar.gz
|
||||
```
|
||||
|
||||
*We strongly recommend that you use an official release of Velero. The tarballs for each release contain the velero command-line client. The code in the main branch of the Velero repository is under active development and is not guaranteed to be stable!*
|
||||
**NOTE:** Its strongly recommend that you use an official release of Velero. The tarballs for each release contain the velero command-line client. The code in the main branch of the Velero repository is under active development and is not guaranteed to be stable!
|
||||
|
||||
2. Untar the release in your `/usr/bin` directory: `tar -xzvf <RELEASE-TARBALL-NAME>.tar.gz`
|
||||
2. Untar the release in your `/usr/bin` directory: `tar -xzvf <RELEASE-TARBALL-NAME>.tar.gz`
|
||||
|
||||
You may choose to rename the directory `velero` for the sake of simplicty: `mv velero-v1.0.0-linux-amd64 velero`
|
||||
You may choose to rename the directory `velero` for the sake of simplicty: `mv velero-v1.0.0-linux-amd64 velero`
|
||||
|
||||
3. Add it to your PATH: `export PATH=/usr/local/bin/velero:$PATH`
|
||||
|
||||
@@ -49,15 +49,15 @@ Usage:
|
||||
|
||||
|
||||
|
||||
## Create A Customer Secret Key
|
||||
## Create A Customer Secret Key
|
||||
|
||||
1. Oracle Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3. This special signing key is an Access Key/Secret Key pair. Follow these steps to [create a Customer Secret Key](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#To4). Refer to this link for more information about [Working with Customer Secret Keys](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#s3).
|
||||
1. Oracle Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3. This special signing key is an Access Key/Secret Key pair. Follow these steps to [create a Customer Secret Key](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#To4). Refer to this link for more information about [Working with Customer Secret Keys](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#s3).
|
||||
|
||||
2. Create a Velero credentials file with your Customer Secret Key:
|
||||
|
||||
```
|
||||
$ vi credentials-velero
|
||||
|
||||
$ vi credentials-velero
|
||||
|
||||
[default]
|
||||
aws_access_key_id=bae031188893d1eb83719648790ac850b76c9441
|
||||
aws_secret_access_key=MmY9heKrWiNVCSZQ2Mf5XTJ6Ys93Bw2d2D6NMSTXZlk=
|
||||
@@ -65,15 +65,15 @@ Usage:
|
||||
|
||||
|
||||
|
||||
## Create An Oracle Object Storage Bucket
|
||||
## Create An Oracle Object Storage Bucket
|
||||
|
||||
Create an Oracle Cloud Object Storage bucket called `velero` in the root compartment of your Oracle Cloud tenancy. Refer to this page for [more information about creating a bucket with Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Tasks/managingbuckets.htm#usingconsole).
|
||||
Create an Oracle Cloud Object Storage bucket called `velero` in the root compartment of your Oracle Cloud tenancy. Refer to this page for [more information about creating a bucket with Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Tasks/managingbuckets.htm#usingconsole).
|
||||
|
||||
|
||||
|
||||
## Install Velero
|
||||
## Install Velero
|
||||
|
||||
You will need the following information to install Velero into your Kubernetes cluster with Oracle Object Storage as the Backup Storage provider:
|
||||
You will need the following information to install Velero into your Kubernetes cluster with Oracle Object Storage as the Backup Storage provider:
|
||||
|
||||
```
|
||||
velero install \
|
||||
@@ -85,14 +85,14 @@ velero install \
|
||||
--backup-location-config region=[region],s3ForcePathStyle="true",s3Url=[storage API endpoint]
|
||||
```
|
||||
|
||||
- `--provider` Because we are using the S3-compatible API, we will use `aws` as our provider.
|
||||
- `--provider` This example uses the S3-compatible API, so use `aws` as the provider.
|
||||
- `--bucket` The name of the bucket created in Oracle Object Storage - in our case this is named `velero`.
|
||||
- ` --prefix` The name of your Oracle Cloud tenancy - in our case this is named `oracle-cloudnative`.
|
||||
- `--use-volume-snapshots=false` Velero does not currently have a volume snapshot plugin for Oracle Cloud creating volume snapshots is disabled.
|
||||
- `--use-volume-snapshots=false` Velero does not have a volume snapshot plugin for Oracle Cloud, so creating volume snapshots is disabled.
|
||||
- `--secret-file` The path to your `credentials-velero` file.
|
||||
- `--backup-location-config` The path to your Oracle Object Storage bucket. This consists of your `region` which corresponds to your Oracle Cloud region name ([List of Oracle Cloud Regions](https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm?Highlight=regions)) and the `s3Url`, the S3-compatible API endpoint for Oracle Object Storage based on your region: `https://oracle-cloudnative.compat.objectstorage.[region name].oraclecloud.com`
|
||||
|
||||
For example:
|
||||
For example:
|
||||
|
||||
```
|
||||
velero install \
|
||||
@@ -104,7 +104,7 @@ velero install \
|
||||
--backup-location-config region=us-phoenix-1,s3ForcePathStyle="true",s3Url=https://oracle-cloudnative.compat.objectstorage.us-phoenix-1.oraclecloud.com
|
||||
```
|
||||
|
||||
This will create a `velero` namespace in your cluster along with a number of CRDs, a ClusterRoleBinding, ServiceAccount, Secret, and Deployment for Velero. If your pod fails to successfully provision, you can troubleshoot your installation by running: `kubectl logs [velero pod name]`.
|
||||
This will create a `velero` namespace in your cluster along with a number of CRDs, a ClusterRoleBinding, ServiceAccount, Secret, and Deployment for Velero. If your pod fails to successfully provision, you can troubleshoot your installation by running: `kubectl logs [velero pod name]`.
|
||||
|
||||
|
||||
|
||||
@@ -117,19 +117,19 @@ kubectl delete namespace/velero clusterrolebinding/velero
|
||||
kubectl delete crds -l component=velero
|
||||
```
|
||||
|
||||
This will remove all resources created by `velero install`.
|
||||
This will remove all resources created by `velero install`.
|
||||
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
After creating the Velero server in your cluster, try this example:
|
||||
After creating the Velero server in your cluster, try this example:
|
||||
|
||||
### Basic example (without PersistentVolumes)
|
||||
|
||||
1. Start the sample nginx app: `kubectl apply -f examples/nginx-app/base.yaml`
|
||||
|
||||
This will create an `nginx-example` namespace with a `nginx-deployment` deployment, and `my-nginx` service.
|
||||
This will create an `nginx-example` namespace with a `nginx-deployment` deployment, and `my-nginx` service.
|
||||
|
||||
```
|
||||
$ kubectl apply -f examples/nginx-app/base.yaml
|
||||
@@ -145,13 +145,13 @@ After creating the Velero server in your cluster, try this example:
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/nginx-deployment-67594d6bf6-4296p 1/1 Running 0 20s
|
||||
pod/nginx-deployment-67594d6bf6-f9r5s 1/1 Running 0 20s
|
||||
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
service/my-nginx LoadBalancer 10.96.69.166 <pending> 80:31859/TCP 21s
|
||||
|
||||
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
deployment.apps/nginx-deployment 2 2 2 2 21s
|
||||
|
||||
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
replicaset.apps/nginx-deployment-67594d6bf6 2 2 2 21s
|
||||
```
|
||||
@@ -164,7 +164,7 @@ After creating the Velero server in your cluster, try this example:
|
||||
Run `velero backup describe nginx-backup` or `velero backup logs nginx-backup` for more details.
|
||||
```
|
||||
|
||||
At this point you can navigate to appropriate bucket, which we called `velero`, in the Oracle Cloud Object Storage console to see the resources backed up using Velero.
|
||||
At this point you can navigate to appropriate bucket, called `velero`, in the Oracle Cloud Object Storage console to see the resources backed up using Velero.
|
||||
|
||||
3. Simulate a disaster by deleting the `nginx-example` namespace: `kubectl delete namespaces nginx-example`
|
||||
|
||||
@@ -191,7 +191,7 @@ After creating the Velero server in your cluster, try this example:
|
||||
Run `velero restore describe nginx-backup-20190604102710` or `velero restore logs nginx-backup-20190604102710` for more details.
|
||||
```
|
||||
|
||||
Running `kubectl get namespaces` will show that the `nginx-example` namespace has been restored along with its contents.
|
||||
Running `kubectl get namespaces` will show that the `nginx-example` namespace has been restored along with its contents.
|
||||
|
||||
5. Run: `velero restore get` to view the list of restored resources. After the restore finishes, the output looks like the following:
|
||||
|
||||
@@ -201,14 +201,14 @@ After creating the Velero server in your cluster, try this example:
|
||||
nginx-backup-20190604104249 nginx-backup Completed 0 0 2019-06-04 10:42:39 -0700 PDT <none>
|
||||
```
|
||||
|
||||
NOTE: The restore can take a few moments to finish. During this time, the `STATUS` column reads `InProgress`.
|
||||
NOTE: The restore can take a few moments to finish. During this time, the `STATUS` column reads `InProgress`.
|
||||
|
||||
After a successful restore, the `STATUS` column shows `Completed`, and `WARNINGS` and `ERRORS` will show `0`. All objects in the `nginx-example` namespace should be just as they were before you deleted them.
|
||||
|
||||
If there are errors or warnings, for instance if the `STATUS` column displays `FAILED` instead of `InProgress`, you can look at them in detail with `velero restore describe <RESTORE_NAME>`
|
||||
|
||||
|
||||
6. Clean up the environment with `kubectl delete -f examples/nginx-app/base.yaml`
|
||||
6. Clean up the environment with `kubectl delete -f examples/nginx-app/base.yaml`
|
||||
|
||||
```
|
||||
$ kubectl delete -f examples/nginx-app/base.yaml
|
||||
@@ -229,20 +229,20 @@ After creating the Velero server in your cluster, try this example:
|
||||
This asks the Velero server to delete all backup data associated with `BACKUP_NAME`. You need to do this for each backup you want to permanently delete. A future version of Velero will allow you to delete multiple backups by name or label selector.
|
||||
|
||||
Once fully removed, the backup is no longer visible when you run: `velero backup get BACKUP_NAME` or more generally `velero backup get`:
|
||||
|
||||
|
||||
```
|
||||
$ velero backup get nginx-backup
|
||||
An error occurred: backups.velero.io "nginx-backup" not found
|
||||
```
|
||||
|
||||
```
|
||||
$ velero backup get
|
||||
NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
|
||||
$ velero backup get
|
||||
NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Additional Reading
|
||||
## Additional Reading
|
||||
|
||||
* [Official Velero Documentation](https://velero.io/docs/main/)
|
||||
* [Oracle Cloud Infrastructure Documentation](https://docs.cloud.oracle.com/)
|
||||
|
||||
@@ -68,7 +68,7 @@ When Velero synchronizes backups into a new cluster, VolumeSnapshotContent objec
|
||||
|
||||
The `DeletionPolicy` on the VolumeSnapshotContent will be the same as the `DeletionPolicy` on the VolumeSnapshotClass that was used to create the VolumeSnapshot. Setting a `DeletionPolicy` of `Retain` on the VolumeSnapshotClass will preserve the volume snapshot in the storage system for the lifetime of the Velero backup and will prevent the deletion of the volume snapshot, in the storage system, in the event of a disaster where the namespace with the VolumeSnapshot object may be lost.
|
||||
|
||||
When the Velero backup expires, the VolumeSnapshot objects will be deleted and the VolumeSnapshotContent objects will be updated to have a `DeletionPolicy` of `Delete`, in order to free space on the storage system.
|
||||
When the Velero backup expires, the VolumeSnapshot objects will be deleted and the VolumeSnapshotContent objects will be updated to have a `DeletionPolicy` of `Delete`, to free space on the storage system.
|
||||
|
||||
For more details on how each plugin works, see the [CSI plugin repo][2]'s documentation.
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ You will need to give your plugin(s) a name when registering them by calling the
|
||||
|
||||
## Plugin Kinds
|
||||
|
||||
Velero currently supports the following kinds of plugins:
|
||||
Velero supports the following kinds of plugins:
|
||||
|
||||
- **Object Store** - persists and retrieves backups, backup logs and restore logs
|
||||
- **Volume Snapshotter** - creates volume snapshots (during backup) and restores volumes from snapshots (during restore)
|
||||
@@ -46,7 +46,7 @@ plugins will also emit debug-level logs. See the [sample repository][1] for an e
|
||||
|
||||
## Plugin Configuration
|
||||
|
||||
Velero uses a ConfigMap-based convention for providing configuration to plugins. If your plugin needs to be configured at runtime,
|
||||
Velero uses a ConfigMap-based convention for providing configuration to plugins. If your plugin needs to be configured at runtime,
|
||||
define a ConfigMap like the following:
|
||||
|
||||
```yaml
|
||||
@@ -56,19 +56,19 @@ metadata:
|
||||
# any name can be used; Velero uses the labels (below)
|
||||
# to identify it rather than the name
|
||||
name: my-plugin-config
|
||||
|
||||
|
||||
# must be in the namespace where the velero deployment
|
||||
# is running
|
||||
namespace: velero
|
||||
|
||||
|
||||
labels:
|
||||
# this value-less label identifies the ConfigMap as
|
||||
# config for a plugin (i.e. the built-in change storageclass
|
||||
# config for a plugin (the built-in change storageclass
|
||||
# restore item action plugin)
|
||||
velero.io/plugin-config: ""
|
||||
|
||||
|
||||
# add a label whose key corresponds to the fully-qualified
|
||||
# plugin name (e.g. mydomain.io/my-plugin-name), and whose
|
||||
# plugin name (for example mydomain.io/my-plugin-name), and whose
|
||||
# value is the plugin type (BackupItemAction, RestoreItemAction,
|
||||
# ObjectStore, or VolumeSnapshotter)
|
||||
<fully-qualified-plugin-name>: <plugin-type>
|
||||
|
||||
@@ -44,7 +44,7 @@ into the Velero server pod. Ensure the following:
|
||||
#### Using kube2iam
|
||||
This means that Velero can't read the content of the S3 bucket. Ensure the following:
|
||||
|
||||
* There is a Trust Policy document allowing the role used by kube2iam to assume Velero's role, as stated in the AWS config documentation.
|
||||
* A Trust Policy document exists that allows the role used by kube2iam to assume Velero's role, as stated in the AWS config documentation.
|
||||
* The new Velero role has all the permissions listed in the documentation regarding S3.
|
||||
|
||||
|
||||
|
||||
@@ -93,13 +93,13 @@ Errors:
|
||||
|
||||
## Structure
|
||||
|
||||
Errors appear for incomplete or partial restores. Warnings appear for non-blocking issues (e.g. the
|
||||
Errors appear for incomplete or partial restores. Warnings appear for non-blocking issues, for example, the
|
||||
restore looks "normal" and all resources referenced in the backup exist in some form, although some
|
||||
of them may have been pre-existing).
|
||||
of them may have been pre-existing.
|
||||
|
||||
Both errors and warnings are structured in the same way:
|
||||
|
||||
* `Velero`: A list of system-related issues encountered by the Velero server (e.g. couldn't read directory).
|
||||
* `Velero`: A list of system-related issues encountered by the Velero server. For example, Velero couldn't read a directory.
|
||||
|
||||
* `Cluster`: A list of issues related to the restore of cluster-scoped resources.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: "Hooks"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
Velero currently supports executing commands in containers in pods during a backup.
|
||||
Velero supports executing commands in containers in pods during a backup.
|
||||
|
||||
## Backup Hooks
|
||||
|
||||
@@ -49,10 +49,10 @@ spec.
|
||||
|
||||
## Hook Example with fsfreeze
|
||||
|
||||
We are going to walk through using both pre and post hooks for freezing a file system. Freezing the
|
||||
This examples walks you through using both pre and post hooks for freezing a file system. Freezing the
|
||||
file system is useful to ensure that all pending disk I/O operations have completed prior to taking a snapshot.
|
||||
|
||||
We will be using [examples/nginx-app/with-pv.yaml][2] for this example. Follow the [steps for your provider][3] to
|
||||
This example uses [examples/nginx-app/with-pv.yaml][2]. Follow the [steps for your provider][3] to
|
||||
setup this example.
|
||||
|
||||
### Annotations
|
||||
|
||||
@@ -7,7 +7,7 @@ Each Velero operation -- on-demand backup, scheduled backup, restore -- is a cus
|
||||
|
||||
You can back up or restore all objects in your cluster, or you can filter objects by type, namespace, and/or label.
|
||||
|
||||
Velero is ideal for the disaster recovery use case, as well as for snapshotting your application state, prior to performing system operations on your cluster (e.g. upgrades).
|
||||
Velero is ideal for the disaster recovery use case, as well as for snapshotting your application state, prior to performing system operations on your cluster, like upgrades.
|
||||
|
||||
## On-demand backups
|
||||
|
||||
@@ -67,7 +67,7 @@ When you create a backup, you can specify a TTL (time to live) by adding the fla
|
||||
* All PersistentVolume snapshots
|
||||
* All associated Restores
|
||||
|
||||
The TTL flag allows the user to specify the backup retention period with the value specified in hours, minutes and seconds in the form `--ttl 24h0m0s`. If not specified, a default TTL value of 30 days will be applied.
|
||||
The TTL flag allows the user to specify the backup retention period with the value specified in hours, minutes and seconds in the form `--ttl 24h0m0s`. If not specified, a default TTL value of 30 days will be applied.
|
||||
|
||||
## Object storage sync
|
||||
|
||||
@@ -82,4 +82,3 @@ Likewise, if a backup object exists in Kubernetes but not in object storage, it
|
||||
[20]: https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions
|
||||
[21]: https://kubernetes.io/docs/concepts/api-extension/custom-resources/#custom-controllers
|
||||
[22]: https://github.com/coreos/etcd
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ This document describes Velero's image tagging policy.
|
||||
|
||||
`velero/velero:<SemVer>`
|
||||
|
||||
Velero follows the [Semantic Versioning](http://semver.org/) standard for releases. Each tag in the `github.com/vmware-tanzu/velero` repository has a matching image, e.g. `velero/velero:v1.0.0`.
|
||||
Velero follows the [Semantic Versioning](http://semver.org/) standard for releases. Each tag in the `github.com/vmware-tanzu/velero` repository has a matching image, `velero/velero:v1.0.0`.
|
||||
|
||||
### Latest
|
||||
|
||||
|
||||
@@ -7,17 +7,17 @@ layout: docs
|
||||
|
||||
Velero has two custom resources, `BackupStorageLocation` and `VolumeSnapshotLocation`, that are used to configure where Velero backups and their associated persistent volume snapshots are stored.
|
||||
|
||||
A `BackupStorageLocation` is defined as a bucket, a prefix within that bucket under which all Velero data should be stored, and a set of additional provider-specific fields (e.g. AWS region, Azure storage account, etc.) The [API documentation][1] captures the configurable parameters for each in-tree provider.
|
||||
A `BackupStorageLocation` is defined as a bucket, a prefix within that bucket under which all Velero data is stored, and a set of additional provider-specific fields (AWS region, Azure storage account, etc.) The [API documentation][1] captures the configurable parameters for each in-tree provider.
|
||||
|
||||
A `VolumeSnapshotLocation` is defined entirely by provider-specific fields (e.g. AWS region, Azure resource group, Portworx snapshot type, etc.) The [API documentation][2] captures the configurable parameters for each in-tree provider.
|
||||
A `VolumeSnapshotLocation` is defined entirely by provider-specific fields (AWS region, Azure resource group, Portworx snapshot type, etc.) The [API documentation][2] captures the configurable parameters for each in-tree provider.
|
||||
|
||||
The user can pre-configure one or more possible `BackupStorageLocations` and one or more `VolumeSnapshotLocations`, and can select *at backup creation time* the location in which the backup and associated snapshots should be stored.
|
||||
|
||||
This configuration design enables a number of different use cases, including:
|
||||
|
||||
- Take snapshots of more than one kind of persistent volume in a single Velero backup (e.g. in a cluster with both EBS volumes and Portworx volumes)
|
||||
- Take snapshots of more than one kind of persistent volume in a single Velero backup. For example, in a cluster with both EBS volumes and Portworx volumes
|
||||
- Have some Velero backups go to a bucket in an eastern USA region, and others go to a bucket in a western USA region
|
||||
- For volume providers that support it (e.g. Portworx), have some snapshots be stored locally on the cluster and have others be stored in the cloud
|
||||
- For volume providers that support it, like Portworx, you can have some snapshots stored locally on the cluster and have others stored in the cloud
|
||||
|
||||
## Limitations / Caveats
|
||||
|
||||
@@ -27,15 +27,15 @@ This configuration design enables a number of different use cases, including:
|
||||
|
||||
- Each Velero backup has one `BackupStorageLocation`, and one `VolumeSnapshotLocation` per volume provider. It is not possible (yet) to send a single Velero backup to multiple backup storage locations simultaneously, or a single volume snapshot to multiple locations simultaneously. However, you can always set up multiple scheduled backups that differ only in the storage locations used if redundancy of backups across locations is important.
|
||||
|
||||
- Cross-provider snapshots are not supported. If you have a cluster with more than one type of volume (e.g. EBS and Portworx), but you only have a `VolumeSnapshotLocation` configured for EBS, then Velero will **only** snapshot the EBS volumes.
|
||||
- Cross-provider snapshots are not supported. If you have a cluster with more than one type of volume, like EBS and Portworx, but you only have a `VolumeSnapshotLocation` configured for EBS, then Velero will **only** snapshot the EBS volumes.
|
||||
|
||||
- Restic data is stored under a prefix/subdirectory of the main Velero bucket, and will go into the bucket corresponding to the `BackupStorageLocation` selected by the user at backup creation time.
|
||||
|
||||
## Examples
|
||||
|
||||
Let's look at some examples of how we can use this configuration mechanism to address some common use cases:
|
||||
Let's look at some examples of how you can use this configuration mechanism to address some common use cases:
|
||||
|
||||
#### Take snapshots of more than one kind of persistent volume in a single Velero backup (e.g. in a cluster with both EBS volumes and Portworx volumes)
|
||||
#### Take snapshots of more than one kind of persistent volume in a single Velero backup
|
||||
|
||||
During server configuration:
|
||||
|
||||
@@ -95,7 +95,7 @@ velero backup create full-cluster-alternate-location-backup \
|
||||
--storage-location s3-alt-region
|
||||
```
|
||||
|
||||
#### For volume providers that support it (e.g. Portworx), have some snapshots be stored locally on the cluster and have others be stored in the cloud
|
||||
#### For volume providers that support it (like Portworx), have some snapshots be stored locally on the cluster and have others be stored in the cloud
|
||||
|
||||
During server configuration:
|
||||
|
||||
@@ -112,8 +112,8 @@ velero snapshot-location create portworx-cloud \
|
||||
During backup creation:
|
||||
|
||||
```shell
|
||||
# Note that since in this example we have two possible volume snapshot locations for the Portworx
|
||||
# provider, we need to explicitly specify which one to use when creating a backup. Alternately,
|
||||
# Note that since in this example you have two possible volume snapshot locations for the Portworx
|
||||
# provider, you need to explicitly specify which one to use when creating a backup. Alternately,
|
||||
# you can set the --default-volume-snapshot-locations flag on the `velero server` command (run by
|
||||
# the Velero deployment) to specify which location should be used for each provider by default, in
|
||||
# which case you don't need to specify it when creating a backup.
|
||||
|
||||
@@ -5,7 +5,7 @@ layout: docs
|
||||
|
||||
*Using Backups and Restores*
|
||||
|
||||
Velero can help you port your resources from one cluster to another, as long as you point each Velero instance to the same cloud object storage location. In this scenario, we are also assuming that your clusters are hosted by the same cloud provider. **Note that Velero does not natively support the migration of persistent volumes snapshots across cloud providers.** If you would like to migrate volume data between cloud platforms, please enable [restic][2], which will backup volume contents at the filesystem level.
|
||||
Velero can help you port your resources from one cluster to another, as long as you point each Velero instance to the same cloud object storage location. This scenario assumes that your clusters are hosted by the same cloud provider. **Note that Velero does not natively support the migration of persistent volumes snapshots across cloud providers.** If you would like to migrate volume data between cloud platforms, please enable [restic][2], which will backup volume contents at the filesystem level.
|
||||
|
||||
1. *(Cluster 1)* Assuming you haven't already been checkpointing your data with the Velero `schedule` operation, you need to first back up your entire cluster (replacing `<BACKUP-NAME>` as desired):
|
||||
|
||||
@@ -13,7 +13,7 @@ Velero can help you port your resources from one cluster to another, as long as
|
||||
velero backup create <BACKUP-NAME>
|
||||
```
|
||||
|
||||
The default backup retention period, expressed as TTL (time to live), is 30 days (720 hours); you can use the `--ttl <DURATION>` flag to change this as necessary. See [how velero works][1] for more information about backup expiry.
|
||||
The default backup retention period, expressed as TTL (time to live), is 30 days (720 hours); you can use the `--ttl <DURATION>` flag to change this as necessary. See [how velero works][1] for more information about backup expiry.
|
||||
|
||||
1. *(Cluster 2)* Configure `BackupStorageLocations` and `VolumeSnapshotLocations`, pointing to the locations used by *Cluster 1*, using `velero backup-location create` and `velero snapshot-location create`. Make sure to configure the `BackupStorageLocations` as read-only
|
||||
by using the `--access-mode=ReadOnly` flag for `velero backup-location create`.
|
||||
|
||||
@@ -14,9 +14,9 @@ If you do not already have an object storage system, [MinIO][2] is an open-sourc
|
||||
|
||||
### (Optional) Selecting volume snapshot providers
|
||||
|
||||
If you need to back up persistent volume data, you must select a volume backup solution. [Supported providers][0] contains information on the supported options.
|
||||
If you need to back up persistent volume data, you must select a volume backup solution. [Supported providers][0] contains information on the supported options.
|
||||
|
||||
For example, if you use [Portworx][4] for persistent storage, you can install their Velero plugin to get native Portworx snapshots as part of your Velero backups.
|
||||
For example, if you use [Portworx][4] for persistent storage, you can install their Velero plugin to get native Portworx snapshots as part of your Velero backups.
|
||||
|
||||
If there is no native snapshot plugin available for your storage platform, you can use Velero's [restic integration][1], which provides a platform-agnostic file-level backup solution for volume data.
|
||||
|
||||
@@ -34,7 +34,7 @@ First, download the Velero image, tag it for the your private registry, then upl
|
||||
|
||||
```bash
|
||||
PRIVATE_REG=<your private registry>
|
||||
VELERO_VERSION=<version of Velero you're targetting, e.g. v1.4.0>
|
||||
VELERO_VERSION=<version of Velero you're targeting, for example v1.4.0>
|
||||
|
||||
docker pull velero/velero:$VELERO_VERSION
|
||||
docker tag velero/velero:$VELERO_VERSION $PRIVATE_REG/velero:$VELERO_VERSION
|
||||
@@ -47,7 +47,7 @@ Next, repeat these steps for any plugins you may need. This example will use the
|
||||
|
||||
```bash
|
||||
PRIVATE_REG=<your private registry>
|
||||
PLUGIN_VERSION=<version of plugin you're targetting, e.g. v1.0.2>
|
||||
PLUGIN_VERSION=<version of plugin you're targeting, for example v1.0.2>
|
||||
|
||||
docker pull velero/velero-plugin-for-aws:$PLUGIN_VERSION
|
||||
docker tag velero/velero-plugin-for-aws:$PLUGIN_VERSION $PRIVATE_REG/velero-plugin-for-aws:$PLUGIN_VERSION
|
||||
@@ -60,7 +60,7 @@ If you are using restic, you will also need to upload the restic helper image.
|
||||
|
||||
```bash
|
||||
PRIVATE_REG=<your private registry>
|
||||
VELERO_VERSION=<version of Velero you're targetting, e.g. v1.4.0>
|
||||
VELERO_VERSION=<version of Velero you're targeting, for example v1.4.0>
|
||||
|
||||
docker pull velero/velero-restic-restore-helper:$VELERO_VERSION
|
||||
docker tag velero/velero-restic-restore-helper:$VELERO_VERSION $PRIVATE_REG/velero-restic-restore-helper:$VELERO_VERSION
|
||||
|
||||
@@ -63,9 +63,9 @@ Note that this file includes detailed info about your volume snapshots in the `s
|
||||
|
||||
## Output File Format Versioning
|
||||
|
||||
The Velero output file format is intended to be relatively stable, but may change over time in order to support new features.
|
||||
The Velero output file format is intended to be relatively stable, but may change over time to support new features.
|
||||
|
||||
In order to accommodate this, Velero follows [Semantic Versioning](http://semver.org/) for the file format version.
|
||||
To accommodate this, Velero follows [Semantic Versioning](http://semver.org/) for the file format version.
|
||||
|
||||
Minor and patch versions will indicate backwards-compatible changes that previous versions of Velero can restore, including new directories or files.
|
||||
|
||||
@@ -78,12 +78,12 @@ However, a major version release of Velero does not necessarily mean that the ba
|
||||
|
||||
### File Format Version: 1.1 (Current)
|
||||
|
||||
In version 1.1, we have added the support of API groups versions as part of the backup (previously, only the preferred version of each API Groups was backed up). Each resource has one or more sub-directories, one sub-directory for each supported version of the API group. The preferred version API Group of each resource has the suffix "-preferredversion" as part of the sub-directory name. For backward compatibility, we kept the classic directory structure without the API Group version, which sits on the same level as the API Group sub-directory versions.
|
||||
By default, only the preferred API group of each resource is backed up.
|
||||
In order to take a backup of all API group versions, you need to run the Velero server with `--features=EnableAPIGroupVersions` feature flag. This is an experimental flag and the restore logic to handle multiple API Group Versions will be added in the future.
|
||||
Version 1.1 added support of API groups versions as part of the backup (previously, only the preferred version of each API Groups was backed up). Each resource has one or more sub-directories, one sub-directory for each supported version of the API group. The preferred version API Group of each resource has the suffix "-preferredversion" as part of the sub-directory name. For backward compatibility, we kept the classic directory structure without the API Group version, which sits on the same level as the API Group sub-directory versions.
|
||||
By default, only the preferred API group of each resource is backed up.
|
||||
To take a backup of all API group versions, you need to run the Velero server with `--features=EnableAPIGroupVersions` feature flag. This is an experimental flag and the restore logic to handle multiple API Group Versions will be added in the future.
|
||||
|
||||
|
||||
When unzipped, a typical backup directory (e.g. `backup1234.tar.gz`) taken with this file format version looks like the following (with the feature flag):
|
||||
When unzipped, a typical backup directory (`backup1234.tar.gz`) taken with this file format version looks like the following (with the feature flag):
|
||||
|
||||
```
|
||||
resources/
|
||||
@@ -185,7 +185,7 @@ resources/
|
||||
|
||||
### File Format Version: 1
|
||||
|
||||
When unzipped, a typical backup directory (e.g. `backup1234.tar.gz`) looks like the following:
|
||||
When unzipped, a typical backup directory (`backup1234.tar.gz`) looks like the following:
|
||||
|
||||
```
|
||||
resources/
|
||||
|
||||
@@ -3,7 +3,7 @@ title: "Restic Integration"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
Velero supports backing up and restoring Kubernetes volumes using a free open-source backup tool called [restic][1]. This support is considered beta quality. Please see the list of [limitations](#limitations) to understand if it currently fits your use case.
|
||||
Velero supports backing up and restoring Kubernetes volumes using a free open-source backup tool called [restic][1]. This support is considered beta quality. Please see the list of [limitations](#limitations) to understand if it fits your use case.
|
||||
|
||||
Velero allows you to take snapshots of persistent volumes as part of your backups if you’re using one of
|
||||
the supported cloud providers’ block storage offerings (Amazon EBS Volumes, Azure Managed Disks, Google Persistent Disks).
|
||||
@@ -34,7 +34,7 @@ To install restic, use the `--use-restic` flag in the `velero install` command.
|
||||
velero install --use-restic
|
||||
```
|
||||
|
||||
When using restic on a storage provider that doesn't currently have Velero support for snapshots, the `--use-volume-snapshots=false` flag prevents an unused `VolumeSnapshotLocation` from being created on installation.
|
||||
When using restic on a storage provider that doesn't have Velero support for snapshots, the `--use-volume-snapshots=false` flag prevents an unused `VolumeSnapshotLocation` from being created on installation.
|
||||
|
||||
### Configure restic DaemonSet spec
|
||||
|
||||
@@ -125,7 +125,7 @@ To mount the correct hostpath to pods volumes, run the restic pod in `privileged
|
||||
```
|
||||
|
||||
|
||||
If restic is not running in a privileged mode, it will not be able to access pods volumes within the mounted hostpath directory because of the default enforced SELinux mode configured in the host system level. You can [create a custom SCC](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html) in order to relax the security in your cluster so that restic pods are allowed to use the hostPath volume plug-in without granting them access to the `privileged` SCC.
|
||||
If restic is not running in a privileged mode, it will not be able to access pods volumes within the mounted hostpath directory because of the default enforced SELinux mode configured in the host system level. You can [create a custom SCC](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html) to relax the security in your cluster so that restic pods are allowed to use the hostPath volume plug-in without granting them access to the `privileged` SCC.
|
||||
|
||||
By default a userland openshift namespace will not schedule pods on all nodes in the cluster.
|
||||
|
||||
@@ -330,13 +330,12 @@ Regardless of how volumes are discovered for backup using restic, the process of
|
||||
## Limitations
|
||||
|
||||
- `hostPath` volumes are not supported. [Local persistent volumes][4] are supported.
|
||||
- Those of you familiar with [restic][1] may know that it encrypts all of its data. We've decided to use a static,
|
||||
common encryption key for all restic repositories created by Velero. **This means that anyone who has access to your
|
||||
- Those of you familiar with [restic][1] may know that it encrypts all of its data. Velero uses a static,
|
||||
common encryption key for all restic repositories it creates. **This means that anyone who has access to your
|
||||
bucket can decrypt your restic backup data**. Make sure that you limit access to the restic bucket
|
||||
appropriately. We plan to implement full Velero backup encryption, including securing the restic encryption keys, in
|
||||
a future release.
|
||||
appropriately.
|
||||
- An incremental backup chain will be maintained across pod reschedules for PVCs. However, for pod volumes that are *not*
|
||||
PVCs, such as `emptyDir` volumes, when a pod is deleted/recreated (e.g. by a ReplicaSet/Deployment), the next backup of those
|
||||
PVCs, such as `emptyDir` volumes, when a pod is deleted/recreated (for example, by a ReplicaSet/Deployment), the next backup of those
|
||||
volumes will be full rather than incremental, because the pod volume's lifecycle is assumed to be defined by its pod.
|
||||
- Restic scans each file in a single thread. This means that large files (such as ones storing a database) will take a long time to scan for data deduplication, even if the actual
|
||||
difference is small.
|
||||
@@ -448,7 +447,7 @@ to the container command in the deployment/daemonset pod template spec.
|
||||
|
||||
## How backup and restore work with restic
|
||||
|
||||
We introduced three custom resource definitions and associated controllers:
|
||||
Velero has three custom resource definitions and associated controllers:
|
||||
|
||||
- `ResticRepository` - represents/manages the lifecycle of Velero's [restic repositories][5]. Velero creates
|
||||
a restic repository per namespace when the first restic backup for a namespace is requested. The controller
|
||||
@@ -512,7 +511,7 @@ on to running other init containers/the main containers.
|
||||
|
||||
### Monitor backup annotation
|
||||
|
||||
Velero does not currently provide a mechanism to detect persistent volume claims that are missing the restic backup annotation.
|
||||
Velero does not provide a mechanism to detect persistent volume claims that are missing the restic backup annotation.
|
||||
|
||||
To solve this, a controller was written by Thomann Bits&Beats: [velero-pvc-watcher][7]
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ layout: docs
|
||||
---
|
||||
|
||||
If you are using an S3-Compatible storage provider that is secured with a self-signed certificate, connections to the object store may fail with a `certificate signed by unknown authority` message.
|
||||
In order to proceed, a certificate bundle may be provided when adding the storage provider.
|
||||
To proceed, provide a certificate bundle when adding the storage provider.
|
||||
|
||||
## Trusting a self-signed certificate during installation
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ layout: docs
|
||||
|
||||
### Finding your way around
|
||||
|
||||
You may join the Velero community and contribute in many different ways, including helping us design or test new features. For any significant feature we consider adding, we start with a design document. You may find a list of currently in progress new designs here: https://github.com/vmware-tanzu/velero/pulls?q=is%3Aopen+is%3Apr+label%3ADesign. Feel free to review and help us with your input.
|
||||
You may join the Velero community and contribute in many different ways, including helping us design or test new features. For any significant feature we consider adding, we start with a design document. You may find a list of in progress new designs here: https://github.com/vmware-tanzu/velero/pulls?q=is%3Aopen+is%3Apr+label%3ADesign. Feel free to review and help us with your input.
|
||||
|
||||
You can also vote on issues using :+1: and :-1:, as explained in our [Feature enhancement request][3] and [Bug issue][4] templates. This will help us quantify importance and prioritize issues.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Velero supports a variety of storage providers for different backup and snapshot
|
||||
| [Google Cloud Platform (GCP)][11] | Google Cloud Storage| Google Compute Engine Disks | [Velero plugin for GCP][12] | [GCP Plugin Setup][36] |
|
||||
| [Microsoft Azure][9] | Azure Blob Storage | Azure Managed Disks | [Velero plugin for Microsoft Azure][10] | [Azure Plugin Setup][37] |
|
||||
| [VMware vSphere][39] | 🚫 | vSphere Volumes | [VMware vSphere][39] | [vSphere Plugin Setup][40] |
|
||||
| [Container Storage Interface (CSI)]| 🚫 | CSI Volumes | [Velero plugin for CSI][44] | [CSI Plugin Setup][45] |
|
||||
| [Container Storage Interface (CSI)][44]| 🚫 | CSI Volumes | [Velero plugin for CSI][44] | [CSI Plugin Setup][45] |
|
||||
|
||||
Contact: [#Velero Slack][28], [GitHub Issues][29]
|
||||
|
||||
|
||||
@@ -82,7 +82,7 @@ Here are some things to verify if you receive `SignatureDoesNotMatch` errors:
|
||||
|
||||
## Velero (or a pod it was backing up) restarted during a backup and the backup is stuck InProgress
|
||||
|
||||
Velero cannot currently resume backups that were interrupted. Backups stuck in the `InProgress` phase can be deleted with `kubectl delete backup <name> -n <velero-namespace>`.
|
||||
Velero cannot resume backups that were interrupted. Backups stuck in the `InProgress` phase can be deleted with `kubectl delete backup <name> -n <velero-namespace>`.
|
||||
Backups in the `InProgress` phase have not uploaded any files to object storage.
|
||||
|
||||
## Velero is not publishing prometheus metrics
|
||||
|
||||
@@ -13,37 +13,33 @@ At the root of the project, run:
|
||||
make serve-docs
|
||||
```
|
||||
|
||||
This runs all the Ruby dependencies in a container.
|
||||
This runs all the Hugo dependencies in a container.
|
||||
|
||||
Alternatively, for quickly loading the website, under the `velero/site/` directory run:
|
||||
|
||||
```bash
|
||||
bundle exec jekyll serve --livereload --future
|
||||
hugo serve
|
||||
```
|
||||
|
||||
For more information on how to run the website locally, please see our [jekyll documentation](https://github.com/vmware-tanzu/velero/blob/main/site/README-JEKYLL.md).
|
||||
For more information on how to run the website locally, please see our [Hugo documentation](https://gohugo.io/getting-started/).
|
||||
|
||||
## Adding a blog post
|
||||
|
||||
The `author_name` value must also be included in the tags field so the page that lists the author's posts will work properly (Ex: https://velero.io/tags/carlisia%20campos/).
|
||||
To add a blog post, create a new markdown (.MD) file in the `/site/content/posts/` folder. A blog poost requires the following front matter.
|
||||
|
||||
Note that the tags field can have multiple values.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
author_name: Carlisia Campos
|
||||
tags: ['Carlisia Campos', "release", "how-to"]
|
||||
```yaml
|
||||
title: "Title of the blog"
|
||||
excerpt: Brief summary of thee blog post that appears as a preview on velero.io/blogs
|
||||
author_name: Jane Smith
|
||||
slug: URL-For-Blog
|
||||
# Use different categories that apply to your blog. This is used to connect related blogs on the site
|
||||
categories: ['velero','release']
|
||||
# Image to use for blog. The path is relative to the site/static/ folder
|
||||
image: /img/posts/example-image.jpg
|
||||
# Tag should match author to drive author pages. Tags can have multiple values.
|
||||
tags: ['Velero Team', 'Nolan Brubaker']
|
||||
```
|
||||
|
||||
### Please add an image
|
||||
Include the `author_name` value in tags field so the page that lists the author's posts will work properly, for example https://velero.io/tags/carlisia-campos/.
|
||||
|
||||
If there is no image added to the header of the post, the default Velero logo will be used. This is fine, but not ideal.
|
||||
|
||||
If there's an image that can be used as the blog post icon, the image field must be set to:
|
||||
|
||||
```text
|
||||
image: /img/posts/<your_image_name.png>
|
||||
```
|
||||
|
||||
This image file must be added to the `/site/img/posts` folder.
|
||||
Ideally each blog will have a unique image to use on the blog home page, but if you do not include an image, the default Velero logo will be used instead. Use an image that is less than 70KB and add it to the `/site/static/img/posts` folder.
|
||||
|
||||
@@ -11,7 +11,7 @@ While GitHub issues, milestones, and labels generally work pretty well, the Vele
|
||||
In our effort to minimize tooling while enabling product management insights, we have decided to use [ZenHub Open-Source](https://www.zenhub.com/blog/open-source/) to overlay product and project tracking on top of GitHub.
|
||||
ZenHub is a GitHub application that provides Kanban visualization, Epic tracking, fine-grained prioritization, and more. It's primary backing storage system is existing GitHub issues along with additional metadata stored in ZenHub's database.
|
||||
|
||||
If you are a Velero user or Velero Developer, you do not _need_ to use ZenHub for your regular workflow (e.g to see open bug reports or feature requests, work on pull requests). However, if you'd like to be able to visualize the high-level project goals and roadmap, you will need to use the free version of ZenHub.
|
||||
If you are a Velero user or Velero Developer, you do not _need_ to use ZenHub for your regular workflow (to see open bug reports or feature requests, work on pull requests). However, if you'd like to be able to visualize the high-level project goals and roadmap, you will need to use the free version of ZenHub.
|
||||
|
||||
## Using ZenHub
|
||||
|
||||
|
||||
Reference in New Issue
Block a user