lyndon
GitHub
parent
76d3321917
commit
e6ba774841
|
|
@ -0,0 +1 @@
|
|||
After Pod Volume Backup/Restore refactor, remove all the unreasonable appearance of "restic" word from documents
|
||||
|
|
@ -84,8 +84,8 @@ spec:
|
|||
# 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.
|
||||
ttl: 24h0m0s
|
||||
# Whether restic should be used to take a backup of all pod volumes by default.
|
||||
defaultVolumesToRestic: true
|
||||
# whether pod volume file system backup should be used for all volumes by default.
|
||||
defaultVolumesToFsBackup: true
|
||||
# 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:
|
||||
|
|
|
|||
|
|
@ -82,8 +82,8 @@ spec:
|
|||
# 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.
|
||||
ttl: 24h0m0s
|
||||
# Whether restic should be used to take a backup of all pod volumes by default.
|
||||
defaultVolumesToRestic: true
|
||||
# whether pod volume file system backup should be used for all volumes by default.
|
||||
defaultVolumesToFsBackup: true
|
||||
# The labels you want on backup objects, created from this schedule (instead of copying the labels you have on schedule object itself).
|
||||
# When this field is set, the labels from the Schedule resource are not copied to the Backup resource.
|
||||
metadata:
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Velero supports storage providers for both cloud-provider environments and on-pr
|
|||
|
||||
### Velero on Windows
|
||||
|
||||
Velero does not officially support Windows. In testing, the Velero team was able to backup stateless Windows applications only. The restic integration and backups of stateful applications or PersistentVolumes were not supported.
|
||||
Velero does not officially support Windows. In testing, the Velero team was able to backup stateless Windows applications only. The File System Backup and backups of stateful applications or PersistentVolumes were not supported.
|
||||
|
||||
If you want to perform your own testing of Velero on Windows, you must deploy Velero as a Windows container. Velero does not provide official Windows images, but its possible for you to build your own Velero Windows container image to use. Note that you must build this image on a Windows node.
|
||||
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ Optionally, set the `$VERSION` environment variable to change the image tag or `
|
|||
```bash
|
||||
make container
|
||||
```
|
||||
_Note: To build build container images for both `velero` and `velero-restic-restore-helper`, run: `make all-containers`_
|
||||
_Note: To build build container images for both `velero` and `velero-restore-helper`, run: `make all-containers`_
|
||||
|
||||
### Publishing container images to a registry
|
||||
|
||||
|
|
|
|||
|
|
@ -70,13 +70,13 @@ Example:
|
|||
|
||||
We use a package to generate mocks for our interfaces.
|
||||
|
||||
Example: if you want to change this mock: https://github.com/vmware-tanzu/velero/blob/main/pkg/restic/mocks/restorer.go
|
||||
Example: if you want to change this mock: https://github.com/vmware-tanzu/velero/blob/main/pkg/podvolume/mocks/restorer.go
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
go get github.com/vektra/mockery/.../
|
||||
cd pkg/restic
|
||||
cd pkg/podvolume
|
||||
mockery -name=Restorer
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -71,9 +71,9 @@ velero install \
|
|||
|
||||
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.
|
||||
Additionally, you can specify `--use-node-agent` to enable [File System Backup][16], and `--wait` to wait for the deployment to be ready.
|
||||
|
||||
(Optional) Specify [CPU and memory resource requests and limits][15] for the Velero/restic pods.
|
||||
(Optional) Specify [CPU and memory resource requests and limits][15] for the Velero/node-agent pods.
|
||||
|
||||
Once the installation is complete, remove the default `VolumeSnapshotLocation` that was created by `velero install`, since it's specific to AWS and won't work for IBM Cloud:
|
||||
|
||||
|
|
@ -98,4 +98,4 @@ Uncomment `storageClassName: <YOUR_STORAGE_CLASS_NAME>` and replace with your `S
|
|||
[5]: https://cloud.ibm.com/docs/containers/container_index.html#container_index
|
||||
[14]: http://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
|
||||
[15]: ../customize-installation.md#customize-resource-requests-and-limits
|
||||
[16]: ../restic.md
|
||||
[16]: ../file-system-backup.md
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ If you encounter issues with installing or configuring, see [Debugging Installat
|
|||
|
||||
## Prerequisites
|
||||
|
||||
* Access to a Kubernetes cluster, version 1.7 or later. **Note:** restic support requires Kubernetes version 1.10 or later, or an earlier version with the mount propagation feature enabled. Restic support is not required for this example, but may be of interest later. See [Restic Integration][17].
|
||||
* Access to a Kubernetes cluster, version 1.7 or later. **Note:** File System Backup support requires Kubernetes version 1.10 or later, or an earlier version with the mount propagation feature enabled. File System Backup support is not required for this example, but may be of interest later. See [File System Backup][17].
|
||||
* A DNS server on the cluster
|
||||
* `kubectl` installed
|
||||
* Sufficient disk space to store backups in Minio. You will need sufficient disk space available to handle any
|
||||
|
|
@ -83,7 +83,7 @@ These instructions start the Velero server and a Minio instance that is accessib
|
|||
|
||||
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`). You may need to update AWS plugin version to one that is [compatible](https://github.com/vmware-tanzu/velero-plugin-for-aws#compatibility) with the version of Velero you are installing.
|
||||
|
||||
Additionally, you can specify `--use-restic` to enable restic support, and `--wait` to wait for the deployment to be ready.
|
||||
Additionally, you can specify `--use-node-agent` to enable File System Backup support, and `--wait` to wait for the deployment to be ready.
|
||||
|
||||
This example also assumes you have named your Minio bucket "velero".
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ In this case:
|
|||
|
||||
[1]: #expose-minio-with-service-of-type-nodeport
|
||||
[3]: ../customize-installation.md
|
||||
[17]: ../restic.md
|
||||
[17]: ../file-system-backup.md
|
||||
[18]: ../debugging-restores.md
|
||||
[26]: https://github.com/vmware-tanzu/velero/releases
|
||||
[30]: https://godoc.org/github.com/robfig/cron
|
||||
|
|
|
|||
|
|
@ -39,13 +39,13 @@ aws_secret_access_key=<SecretKey>
|
|||
|
||||
You need to install the Velero CLI first, see [Install the CLI](https://velero.io/docs/v1.5/basic-install/#install-the-cli) for how to install.
|
||||
|
||||
Follow the Velero installation command below to create velero and restic workloads and other necessary resource objects.
|
||||
Follow the Velero installation command below to create velero and node-agent workloads and other necessary resource objects.
|
||||
|
||||
```bash
|
||||
velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.1.0 --bucket <BucketName> \
|
||||
--secret-file ./credentials-velero \
|
||||
--use-restic \
|
||||
--default-volumes-to-restic \
|
||||
--use-node-agent \
|
||||
--default-volumes-to-fs-backup \
|
||||
--backup-location-config \
|
||||
region=ap-guangzhou,s3ForcePathStyle="true",s3Url=https://cos.ap-guangzhou.myqcloud.com
|
||||
```
|
||||
|
|
@ -60,9 +60,9 @@ Description of the parameters:
|
|||
|
||||
- `--secret-file`: Access tencent cloud COS access credential file for the "credentials-velero" credential file created above.
|
||||
|
||||
- `--use-restic`: Back up and restore persistent volume data using the open source free backup tool [restic](https://github.com/restic/restic). However, 'hostPath' volumes are not supported, see the [restic limit](https://velero.io/docs/v1.5/restic/#limitations) for details), an integration that complements Velero's backup capabilities and is recommended to be turned on.
|
||||
- `--use-node-agent`: Enable Velero node-agent daemonset. At present, Velero File System Backup requires this daemonset, so if you are using File System Backup, it needs to be turned on. For the usage and limitation of File System Backup, See [File System Backup](../file-system-backup.md).
|
||||
|
||||
- `--default-volumes-to-restic`: Enable the use of Restic to back up all Pod volumes, provided that the `--use-restic`parameter needs to be turned on.
|
||||
- `--default-volumes-to-fs-backup`: Enable the use of File System Backup to back up all Pod volumes, provided that the `--use-node-agent`parameter needs to be turned on.
|
||||
|
||||
- `--backup-location-config`: Back up the bucket access-related configuration:
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ After executing the installation commands above, the installation process looks
|
|||
|
||||
{{< figure src="/docs/main/contributions/img-for-tencent/9015313121ed7987558c88081b052574.png" width="100%">}}
|
||||
|
||||
After the installation command is complete, wait for the velero and restic workloads to be ready to see if the configured storage location is available.
|
||||
After the installation command is complete, wait for the velero and node-agent workloads to be ready to see if the configured storage location is available.
|
||||
|
||||
Executing the 'velero backup-location get' command to view the storage location status and display "Available" indicates that access to Tencent Cloud COS is OK, as shown in the following image:
|
||||
|
||||
|
|
|
|||
|
|
@ -17,17 +17,17 @@ By default, `velero install` expects a credentials file for your `velero` IAM ac
|
|||
|
||||
If you are using an alternate identity mechanism, such as kube2iam/kiam on AWS, Workload Identity on GKE, etc., that does not require a credentials file, you can specify the `--no-secret` flag instead of `--secret-file`.
|
||||
|
||||
## Enable restic integration
|
||||
## Enable file system backup
|
||||
|
||||
By default, `velero install` does not install Velero's [restic integration][3]. To enable it, specify the `--use-restic` flag.
|
||||
By default, `velero install` does not install Velero's [File System Backup][3]. To enable it, specify the `--use-node-agent` flag.
|
||||
|
||||
If you've already run `velero install` without the `--use-restic` flag, you can run the same command again, including the `--use-restic` flag, to add the restic integration to your existing install.
|
||||
If you've already run `velero install` without the `--use-node-agent` flag, you can run the same command again, including the `--use-node-agent` flag, to add the file system backup to your existing install.
|
||||
|
||||
## Default Pod Volume backup to restic
|
||||
## Default Pod Volume backup to file system backup
|
||||
|
||||
By default, `velero install` does not enable the use of restic to take backups of all pod volumes. You must apply an [annotation](restic.md/#using-opt-in-pod-volume-backup) to every pod which contains volumes for Velero to use restic for the backup.
|
||||
By default, `velero install` does not enable the use of File System Backup (FSB) to take backups of all pod volumes. You must apply an [annotation](file-system-backup.md/#using-opt-in-pod-volume-backup) to every pod which contains volumes for Velero to use FSB for the backup.
|
||||
|
||||
If you are planning to only use restic for volume backups, you can run the `velero install` command with the `--default-volumes-to-restic` flag. This will default all pod volumes backups to use restic without having to apply annotations to pods. Note that when this flag is set during install, Velero will always try to use restic to perform the backup, even want an individual backup to use volume snapshots, by setting the `--snapshot-volumes` flag in the `backup create` command. Alternatively, you can set the `--default-volumes-to-restic` on an individual backup to to make sure Velero uses Restic for each volume being backed up.
|
||||
If you are planning to only use FSB for volume backups, you can run the `velero install` command with the `--default-volumes-to-fs-backup` flag. This will default all pod volumes backups to use FSB without having to apply annotations to pods. Note that when this flag is set during install, Velero will always try to use FSB to perform the backup, even want an individual backup to use volume snapshots, by setting the `--snapshot-volumes` flag in the `backup create` command. Alternatively, you can set the `--default-volumes-to-fs-backup` on an individual backup to to make sure Velero uses FSB for each volume being backed up.
|
||||
|
||||
## Enable features
|
||||
|
||||
|
|
@ -43,15 +43,15 @@ velero install --features=EnableCSI
|
|||
|
||||
Another example is enabling the support of multiple API group versions, as documented at [- -features=EnableAPIGroupVersions](enable-api-group-versions-feature.md).
|
||||
|
||||
Feature flags, passed to `velero install` will be passed to the Velero deployment and also to the `restic` daemon set, if `--use-restic` flag is used.
|
||||
Feature flags, passed to `velero install` will be passed to the Velero deployment and also to the `node-agent` daemon set, if `--use-node-agent` flag is used.
|
||||
|
||||
Similarly, features may be disabled by removing the corresponding feature flags from the `--features` flag.
|
||||
|
||||
Enabling and disabling feature flags will require modifying the Velero deployment and also the restic daemonset. This may be done from the CLI by uninstalling and re-installing Velero, or by editing the `deploy/velero` and `daemonset/restic` resources in-cluster.
|
||||
Enabling and disabling feature flags will require modifying the Velero deployment and also the node-agent daemonset. This may be done from the CLI by uninstalling and re-installing Velero, or by editing the `deploy/velero` and `daemonset/node-agent` resources in-cluster.
|
||||
|
||||
```bash
|
||||
$ kubectl -n velero edit deploy/velero
|
||||
$ kubectl -n velero edit daemonset/restic
|
||||
$ kubectl -n velero edit daemonset/node-agent
|
||||
```
|
||||
|
||||
### Enable client side features
|
||||
|
|
@ -87,10 +87,10 @@ the config file setting.
|
|||
|
||||
## Customize resource requests and limits
|
||||
|
||||
At installation, Velero sets default resource requests and limits for the Velero pod and the restic pod, if you using the [restic integration](/docs/main/restic/).
|
||||
At installation, Velero sets default resource requests and limits for the Velero pod and the node-agent pod, if you using the [File System Backup][3].
|
||||
|
||||
{{< table caption="Velero Customize resource requests and limits defaults" >}}
|
||||
|Setting|Velero pod defaults|restic pod defaults|
|
||||
|Setting|Velero pod defaults|node-agent pod defaults|
|
||||
|--- |--- |--- |
|
||||
|CPU request|500m|500m|
|
||||
|Memory requests|128Mi|512Mi|
|
||||
|
|
@ -98,9 +98,9 @@ At installation, Velero sets default resource requests and limits for the Velero
|
|||
|Memory limit|512Mi|1024Mi|
|
||||
{{< /table >}}
|
||||
|
||||
Depending on the cluster resources, especially if you are using Restic, you may need to increase these defaults. Through testing, the Velero maintainers have found these defaults work well when backing up and restoring 1000 or less resources and total size of files is 100GB or below. If the resources you are planning to backup or restore exceed this, you will need to increase the CPU or memory resources available to Velero. In general, the Velero maintainer's testing found that backup operations needed more CPU & memory resources but were less time-consuming than restore operations, when comparing backing up and restoring the same amount of data. The exact CPU and memory limits you will need depend on the scale of the files and directories of your resources and your hardware. It's recommended that you perform your own testing to find the best resource limits for your clusters and resources.
|
||||
Depending on the cluster resources, you may need to increase these defaults. Through testing, the Velero maintainers have found these defaults work well when backing up and restoring 1000 or less resources and total size of files is 100GB or below. If the resources you are planning to backup or restore exceed this, you will need to increase the CPU or memory resources available to Velero. In general, the Velero maintainer's testing found that backup operations needed more CPU & memory resources but were less time-consuming than restore operations, when comparing backing up and restoring the same amount of data. The exact CPU and memory limits you will need depend on the scale of the files and directories of your resources and your hardware. It's recommended that you perform your own testing to find the best resource limits for your clusters and resources.
|
||||
|
||||
Due to a [known Restic issue](https://github.com/restic/restic/issues/2446), the Restic pod will consume large amounts of memory, especially if you are backing up millions of tiny files and directories. If you are planning to use Restic to backup 100GB of data or more, you will need to increase the resource limits to make sure backups complete successfully.
|
||||
You may need to increase the resource limits if you are using File System Backup, see the details in [File System Backup][3].
|
||||
|
||||
### Install with custom resource requests and limits
|
||||
|
||||
|
|
@ -112,17 +112,17 @@ velero install \
|
|||
--velero-pod-mem-request <MEMORY_REQUEST> \
|
||||
--velero-pod-cpu-limit <CPU_LIMIT> \
|
||||
--velero-pod-mem-limit <MEMORY_LIMIT> \
|
||||
[--use-restic] \
|
||||
[--default-volumes-to-restic] \
|
||||
[--restic-pod-cpu-request <CPU_REQUEST>] \
|
||||
[--restic-pod-mem-request <MEMORY_REQUEST>] \
|
||||
[--restic-pod-cpu-limit <CPU_LIMIT>] \
|
||||
[--restic-pod-mem-limit <MEMORY_LIMIT>]
|
||||
[--use-node-agent] \
|
||||
[--default-volumes-to-fs-backup] \
|
||||
[--node-agent-pod-cpu-request <CPU_REQUEST>] \
|
||||
[--node-agent-pod-mem-request <MEMORY_REQUEST>] \
|
||||
[--node-agent-pod-cpu-limit <CPU_LIMIT>] \
|
||||
[--node-agent-pod-mem-limit <MEMORY_LIMIT>]
|
||||
```
|
||||
|
||||
### Update resource requests and limits after install
|
||||
|
||||
After installation you can adjust the resource requests and limits in the Velero Deployment spec or restic DeamonSet spec, if you are using the restic integration.
|
||||
After installation you can adjust the resource requests and limits in the Velero Deployment spec or node-agent DeamonSet spec, if you are using the File System Backup.
|
||||
|
||||
**Velero pod**
|
||||
|
||||
|
|
@ -133,16 +133,16 @@ kubectl patch deployment velero -n velero --patch \
|
|||
'{"spec":{"template":{"spec":{"containers":[{"name": "velero", "resources": {"limits":{"cpu": "1", "memory": "512Mi"}, "requests": {"cpu": "1", "memory": "128Mi"}}}]}}}}'
|
||||
```
|
||||
|
||||
**restic pod**
|
||||
**node-agent pod**
|
||||
|
||||
Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the restic DeamonSet spec.
|
||||
Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the node-agent DeamonSet spec.
|
||||
|
||||
```bash
|
||||
kubectl patch daemonset restic -n velero --patch \
|
||||
'{"spec":{"template":{"spec":{"containers":[{"name": "restic", "resources": {"limits":{"cpu": "1", "memory": "1024Mi"}, "requests": {"cpu": "1", "memory": "512Mi"}}}]}}}}'
|
||||
kubectl patch daemonset node-agent -n velero --patch \
|
||||
'{"spec":{"template":{"spec":{"containers":[{"name": "node-agent", "resources": {"limits":{"cpu": "1", "memory": "1024Mi"}, "requests": {"cpu": "1", "memory": "512Mi"}}}]}}}}'
|
||||
```
|
||||
|
||||
Additionally, you may want to update the the default Velero restic pod operation timeout (default 240 minutes) to allow larger backups more time to complete. You can adjust this timeout by adding the `- --restic-timeout` argument to the Velero Deployment spec.
|
||||
Additionally, you may want to update the the default File System Backup operation timeout (default 240 minutes) to allow larger backups more time to complete. You can adjust this timeout by adding the `- --fs-backup-timeout` argument to the Velero Deployment spec.
|
||||
|
||||
**NOTE:** Changes made to this timeout value will revert back to the default value if you re-run the Velero install command.
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ Additionally, you may want to update the the default Velero restic pod operation
|
|||
kubectl edit deploy velero -n velero
|
||||
```
|
||||
|
||||
1. Add `- --restic-timeout` to `spec.template.spec.containers`.
|
||||
1. Add `- --fs-backup-timeout` to `spec.template.spec.containers`.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
|
|
@ -160,7 +160,7 @@ Additionally, you may want to update the the default Velero restic pod operation
|
|||
spec:
|
||||
containers:
|
||||
- args:
|
||||
- --restic-timeout=240m
|
||||
- --fs-backup-timeout=240m
|
||||
```
|
||||
|
||||
## Configure more than one storage location for backups or volume snapshots
|
||||
|
|
@ -380,7 +380,7 @@ If you get an error like `complete:13: command not found: compdef`, then add the
|
|||
|
||||
[1]: https://github.com/vmware-tanzu/velero/releases/latest
|
||||
[2]: namespace.md
|
||||
[3]: restic.md
|
||||
[3]: file-system-backup.md
|
||||
[4]: on-premises.md
|
||||
[6]: velero-install.md#usage
|
||||
[7]: https://github.com/vmware-tanzu/velero/issues/2077
|
||||
|
|
|
|||
|
|
@ -37,13 +37,13 @@ This configuration design enables a number of different use cases, including:
|
|||
|
||||
- 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.
|
||||
- File System Backup 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.
|
||||
|
||||
- Velero's backups are split into 2 pieces - the metadata stored in object storage, and snapshots/backups of the persistent volume data. Right now, Velero *itself* does not encrypt either of them, instead it relies on the native mechanisms in the object and snapshot systems. A special case is restic, which backs up the persistent volume data at the filesystem level and send it to Velero's object storage.
|
||||
- Velero's backups are split into 2 pieces - the metadata stored in object storage, and snapshots/backups of the persistent volume data. Right now, Velero *itself* does not encrypt either of them, instead it relies on the native mechanisms in the object and snapshot systems. A special case is File System Backup, which backs up the persistent volume data at the filesystem level and send it to Velero's object storage.
|
||||
|
||||
- Velero's compression for object metadata is limited, using Golang's tar implementation. In most instances, Kubernetes objects are limited to 1.5MB in size, but many don't approach that, meaning that compression may not be necessary. Note that restic has not yet implemented compression, but does have de-deduplication capabilities.
|
||||
- Velero's compression for object metadata is limited, using Golang's tar implementation. In most instances, Kubernetes objects are limited to 1.5MB in size, but many don't approach that, meaning that compression may not be necessary. Note that File System Backup has not yet implemented compression, but does have de-deduplication capabilities.
|
||||
|
||||
- If you have [multiple](customize-installation.md/#configure-more-than-one-storage-location-for-backups-or-volume-snapshots) `VolumeSnapshotLocations` configured for a provider, you must always specify a valid `VolumeSnapshotLocation` when creating a backup, even if you are using [Restic](restic.md) for volume backups. You can optionally decide to set the [`--default-volume-snapshot-locations`](customize-locations.md#set-default-backup-storage-location-or-volume-snapshot-locations) flag using the `velero server`, which lists the default `VolumeSnapshotLocation` Velero should use if a `VolumeSnapshotLocation` is not specified when creating a backup. If you only have one `VolumeSnapshotLocation` for a provider, Velero will automatically use that location as the default.
|
||||
- If you have [multiple](customize-installation.md/#configure-more-than-one-storage-location-for-backups-or-volume-snapshots) `VolumeSnapshotLocations` configured for a provider, you must always specify a valid `VolumeSnapshotLocation` when creating a backup, even if you are using [File System Backup](file-system-backup.md) for volume backups. You can optionally decide to set the [`--default-volume-snapshot-locations`](customize-locations.md#set-default-backup-storage-location-or-volume-snapshot-locations) flag using the `velero server`, which lists the default `VolumeSnapshotLocation` Velero should use if a `VolumeSnapshotLocation` is not specified when creating a backup. If you only have one `VolumeSnapshotLocation` for a provider, Velero will automatically use that location as the default.
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ The "Backup and Restore" test cases below describe general backup and restore fu
|
|||
#### Backup and Restore
|
||||
|
||||
- Verify that a backup and restore using Volume Snapshots can be performed
|
||||
- Verify that a backup and restore using Restic can be performed
|
||||
- Verify that a backup and restore using File System Backup can be performed
|
||||
- Verify that a backup of a cluster workload can be restored in a new cluster
|
||||
- Verify that an installation using the latest version can be used to restore from backups created with the last 3 versions.
|
||||
- e.g. Install Velero 1.6 and use it to restore backups from Velero v1.3, v1.4, v1.5.
|
||||
|
|
@ -61,9 +61,9 @@ The following are test cases that are not currently performed as part of a Veler
|
|||
- Verify that backups that exceed their TTL are deleted
|
||||
- Verify that existing backups in object storage are synced to Velero
|
||||
|
||||
### Restic repository test cases
|
||||
### Backup repository test cases
|
||||
|
||||
- Verify that restic repository maintenance is performed as the specified interval
|
||||
- Verify that backup repository maintenance is performed as the specified interval
|
||||
|
||||
### Backup Hooks
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ The following are test cases that are not currently performed as part of a Veler
|
|||
|
||||
- Verify that an InitContainer restore hook provided via pod annotation is performed during restore
|
||||
- Verify that an InitContainer restore hook provided via Restore spec is performed during restore
|
||||
- Verify that an InitContainer restore hook provided via Restore spec is performed during restore that includes restoring restic volumes
|
||||
- Verify that an InitContainer restore hook provided via Restore spec is performed during restore that includes restoring File System Backup volumes
|
||||
- Verify that an Exec restore hook provided via pod annotation is performed during restore
|
||||
- Verify that an Exec restore hook provided via Restore spec is performed during restore
|
||||
|
||||
|
|
|
|||
|
|
@ -11,10 +11,10 @@ This page outlines a cluster migration scenario and some common configurations y
|
|||
|
||||
Before migrating you should consider the following,
|
||||
|
||||
* 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, enable [restic](restic.md), which will backup volume contents at the filesystem level.
|
||||
* 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, enable [File System Backup](file-system-backup.md), which will backup volume contents at the filesystem level.
|
||||
* Velero doesn't support restoring into a cluster with a lower Kubernetes version than where the backup was taken.
|
||||
* Migrating workloads across clusters that are not running the same version of Kubernetes might be possible, but some factors need to be considered before migration, including the compatibility of API groups between clusters for each custom resource. If a Kubernetes version upgrade breaks the compatibility of core/native API groups, migrating with Velero will not be possible without first updating the impacted custom resources. For more information about API group versions, please see [EnableAPIGroupVersions](enable-api-group-versions-feature.md).
|
||||
* The Velero plugin for AWS and Azure does not support migrating data between regions. If you need to do this, you must use [restic](restic.md).
|
||||
* The Velero plugin for AWS and Azure does not support migrating data between regions. If you need to do this, you must use [File System Backup](file-system-backup.md).
|
||||
|
||||
|
||||
## Migration Scenario
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ If you need to back up persistent volume data, you must select a volume backup s
|
|||
|
||||
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.
|
||||
If there is no native snapshot plugin available for your storage platform, you can use Velero's [File System Backup][1], which provides a platform-agnostic file-level backup solution for volume data.
|
||||
|
||||
### Air-gapped deployments
|
||||
|
||||
|
|
@ -54,17 +54,17 @@ docker tag velero/velero-plugin-for-aws:$PLUGIN_VERSION $PRIVATE_REG/velero-plug
|
|||
docker push $PRIVATE_REG/velero-plugin-for-aws:$PLUGIN_VERSION
|
||||
```
|
||||
|
||||
#### Preparing the restic helper image (optional)
|
||||
#### Preparing the restore helper image (optional)
|
||||
|
||||
If you are using restic, you will also need to upload the restic helper image.
|
||||
If you are using File System Backup, you will also need to upload the restore helper image.
|
||||
|
||||
```bash
|
||||
PRIVATE_REG=<your private registry>
|
||||
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
|
||||
docker push $PRIVATE_REG/velero-restic-restore-helper:$VELERO_VERSION
|
||||
docker pull velero/velero-restore-helper:$VELERO_VERSION
|
||||
docker tag velero/velero-restore-helper:$VELERO_VERSION $PRIVATE_REG/velero-restore-helper:$VELERO_VERSION
|
||||
docker push $PRIVATE_REG/velero-restore-helper:$VELERO_VERSION
|
||||
```
|
||||
|
||||
#### Pulling specific architecture images (optional)
|
||||
|
|
@ -88,7 +88,7 @@ velero install \
|
|||
|
||||
|
||||
[0]: supported-providers.md
|
||||
[1]: restic.md
|
||||
[1]: file-system-backup.md
|
||||
[2]: https://min.io
|
||||
[3]: contributions/minio.md
|
||||
[4]: https://portworx.com
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Velero supports Restore Hooks, custom actions that can be executed during or aft
|
|||
|
||||
Use an `InitContainer` hook to add init containers into a pod before it's restored. You can use these init containers to run any setup needed for the pod to resume running from its backed-up state.
|
||||
The InitContainer added by the restore hook will be the first init container in the `podSpec` of the restored pod.
|
||||
In the case where the pod had volumes backed up using restic, then, the restore hook InitContainer will be added after the `restic-wait` InitContainer.
|
||||
In the case where the pod had volumes backed up using File System Backup, then, the restore hook InitContainer will be added after the `restore-wait` InitContainer.
|
||||
|
||||
NOTE: This ordering can be altered by any mutating webhooks that may be installed in the cluster.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The following is an overview of Velero's restore process that starts after you r
|
|||
|
||||
1. The `RestoreController` notices the new Restore object and performs validation.
|
||||
|
||||
1. The `RestoreController` fetches basic information about the backup being restored, like the [BackupStorageLocation](locations.md) (BSL). It also fetches a tarball of the cluster resources in the backup, any volumes that will be restored using Restic, and any volume snapshots to be restored.
|
||||
1. The `RestoreController` fetches basic information about the backup being restored, like the [BackupStorageLocation](locations.md) (BSL). It also fetches a tarball of the cluster resources in the backup, any volumes that will be restored using File System Backup, and any volume snapshots to be restored.
|
||||
|
||||
1. The `RestoreController` then extracts the tarball of backup cluster resources to the /tmp folder and performs some pre-processing on the resources, including:
|
||||
|
||||
|
|
@ -56,14 +56,14 @@ The following is an overview of Velero's restore process that starts after you r
|
|||
|
||||
* The `RestoreController` adds a `velero.io/backup-name` label with the backup name and a `velero.io/restore-name` with the restore name to the resource. This can help you easily identify restored resources and which backup they were restored from.
|
||||
|
||||
1. The `RestoreController` creates the resource object on the target cluster. If the resource is a PV then the `RestoreController` will restore the PV data from the [durable snapshot](#durable-snapshot-pv-restore), [Restic](#restic-pv-restore), or [CSI snapshot](#csi-pv-restore) depending on how the PV was backed up.
|
||||
1. The `RestoreController` creates the resource object on the target cluster. If the resource is a PV then the `RestoreController` will restore the PV data from the [durable snapshot](#durable-snapshot-pv-restore), [File System Backup](#file-system-backup-pv-restore), or [CSI snapshot](#csi-pv-restore) depending on how the PV was backed up.
|
||||
|
||||
If the resource already exists in the target cluster, which is determined by the Kubernetes API during resource creation, the `RestoreController` will skip the resource. The only [exception](#restore-existing-resource-policy) are Service Accounts, which Velero will attempt to merge differences between the backed up ServiceAccount into the ServiceAccount on the target cluster. You can [change the default existing resource restore policy](#restore-existing-resource-policy) to update resources instead of skipping them using the `--existing-resource-policy`.
|
||||
|
||||
1. Once the resource is created on the target cluster, Velero may take some additional steps or wait for additional processes to complete before moving onto the next resource to restore.
|
||||
|
||||
* If the resource is a Pod, the `RestoreController` will execute any [Restore Hooks](restore-hooks.md) and wait for the hook to finish.
|
||||
* If the resource is a PV restored by Restic, the `RestoreController` waits for Restic’s restore to complete. The `RestoreController` sets a timeout for any resources restored with Restic during a restore. The default timeout is 4 hours, but you can configure this be setting using `--restic-timeout` restore option.
|
||||
* If the resource is a PV restored by File System Backup, the `RestoreController` waits for File System Backup’s restore to complete. The `RestoreController` sets a timeout for any resources restored with File System Backup during a restore. The default timeout is 4 hours, but you can configure this be setting using `--fs-backup-timeout` restore option.
|
||||
* If the resource is a Custom Resource Definition, the `RestoreController` waits for its availability in the cluster. The timeout is 1 minute.
|
||||
|
||||
If any failures happen finishing these steps, the `RestoreController` will log an error in the restore result and will continue restoring.
|
||||
|
|
@ -106,16 +106,16 @@ clusterresourcesets.addons.cluster.x-k8s.io
|
|||
Velero has three approaches when restoring a PV, depending on how the backup was taken.
|
||||
|
||||
1. When restoring a snapshot, Velero statically creates the PV and then binds it to a restored PVC. Velero's PV rename and remap process is used only in this case because this is the only case where Velero creates the PV resource directly.
|
||||
1. When restoring with Restic, Velero uses Kubernetes’ [dynamic provision process](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/) to provision the PV after creating the PVC. In this case, the PV object is not actually created by Velero.
|
||||
1. When restoring with File System Backup, Velero uses Kubernetes’ [dynamic provision process](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/) to provision the PV after creating the PVC. In this case, the PV object is not actually created by Velero.
|
||||
1. When restoring with the [CSI plugin](csi.md), the PV is created from a CSI snapshot by the CSI driver. Velero doesn’t create the PV directly. Instead Velero creates a PVC with its DataSource referring to the CSI VolumeSnapshot object.
|
||||
|
||||
### Snapshot PV Restore
|
||||
|
||||
PV data backed up by durable snapshots is restored by VolumeSnapshot plugins. Velero calls the plugins’ interface to create a volume from a snapshot. The plugin returns the volume’s `volumeID`. This ID is created by storage vendors and will be updated in the PV object created by Velero, so that the PV object is connected to the volume restored from a snapshot.
|
||||
|
||||
### Restic PV Restore
|
||||
### File System Backup PV Restore
|
||||
|
||||
For more information on Restic restores, see the [Restic integration](restic.md#restore) page.
|
||||
For more information on File System Backup restores, see the [File System Backup](file-system-backup.md#restore) page.
|
||||
|
||||
### CSI PV Restore
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ You will need to change this setting on the server to make it work.
|
|||
|
||||
**Note:** The `--insecure-skip-tls-verify` flag is insecure and susceptible to man-in-the-middle attacks and meant to help your testing and developing scenarios in an on-premise environment. Using this flag in production is not recommended.
|
||||
|
||||
Velero provides a way for you to skip TLS verification on the object store when using the [AWS provider plugin](https://github.com/vmware-tanzu/velero-plugin-for-aws) or [Restic](restic.md) by passing the `--insecure-skip-tls-verify` flag with the following Velero commands,
|
||||
Velero provides a way for you to skip TLS verification on the object store when using the [AWS provider plugin](https://github.com/vmware-tanzu/velero-plugin-for-aws) or [File System Backup](file-system-backup.md) by passing the `--insecure-skip-tls-verify` flag with the following Velero commands,
|
||||
|
||||
* velero backup describe
|
||||
* velero backup download
|
||||
|
|
@ -60,6 +60,6 @@ Velero provides a way for you to skip TLS verification on the object store when
|
|||
* velero restore describe
|
||||
* velero restore log
|
||||
|
||||
If true, the object store's TLS certificate will not be checked for validity before Velero connects to the object store or Restic repo. You can permanently skip TLS verification for an object store by setting `Spec.Config.InsecureSkipTLSVerify` to true in the [BackupStorageLocation](api-types/backupstoragelocation.md) CRD.
|
||||
If true, the object store's TLS certificate will not be checked for validity before Velero or backup repository connects to the object storage. You can permanently skip TLS verification for an object store by setting `Spec.Config.InsecureSkipTLSVerify` to true in the [BackupStorageLocation](api-types/backupstoragelocation.md) CRD.
|
||||
|
||||
Note that Velero's Restic integration uses Restic commands to do data transfer between object store and Kubernetes cluster disks. This means that when you specify `--insecure-skip-tls-verify` in Velero operations that involve interacting with Restic, Velero will add the Restic global command parameter `--insecure-tls` to Restic commands.
|
||||
Note that Velero's File System Backup uses Restic or Kopia to do data transfer between object store and Kubernetes cluster disks. This means that when you specify `--insecure-skip-tls-verify` in Velero operations that involve File System Backup, Velero will convey this information to Restic or Kopia. For example, for Restic, Velero will add the Restic global command parameter `--insecure-tls` to Restic commands.
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ _Some storage providers, like Quobyte, may need a different [signature algorithm
|
|||
|
||||
## Non-supported volume snapshots
|
||||
|
||||
In the case you want to take volume snapshots but didn't find a plugin for your provider, Velero has support for snapshotting using restic. Please see the [restic integration][30] documentation.
|
||||
In the case you want to take volume snapshots but didn't find a plugin for your provider, Velero has support for snapshotting using File System Backup. Please see the [File System Backup][30] documentation.
|
||||
|
||||
[0]: https://github.com/aws/aws-sdk-go/aws
|
||||
[1]: contributions/ibm-config.md
|
||||
|
|
@ -65,6 +65,6 @@ In the case you want to take volume snapshots but didn't find a plugin for your
|
|||
[6]: https://github.com/vmware-tanzu/velero-plugin-for-aws/blob/main/backupstoragelocation.md
|
||||
[7]: contributions/tencent-config.md
|
||||
[25]: https://github.com/hpe-storage/velero-plugin
|
||||
[30]: restic.md
|
||||
[30]: file-system-backup.md
|
||||
[36]: https://github.com/vmware-tanzu/velero-plugin-for-gcp#setup
|
||||
[38]: https://www.cloudian.com/
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ layout: docs
|
|||
This document describes how to use [Tilt](https://tilt.dev) with any cluster for a simplified
|
||||
workflow that offers easy deployments and rapid iterative builds.
|
||||
|
||||
This setup allows for continuing deployment of the Velero server and, if specified, any provider plugin or the restic daemonset.
|
||||
This setup allows for continuing deployment of the Velero server and, if specified, any provider plugin or the node-agent daemonset.
|
||||
It does this work by:
|
||||
|
||||
1. Deploying the necessary Kubernetes resources, such as the Velero CRDs and Velero deployment
|
||||
|
|
@ -60,7 +60,7 @@ Here is an example:
|
|||
"allowed_contexts": [
|
||||
"development"
|
||||
],
|
||||
"enable_restic": false,
|
||||
"use_node_agent": false,
|
||||
"create_backup_locations": true,
|
||||
"setup-minio": true,
|
||||
"enable_debug": false,
|
||||
|
|
@ -82,8 +82,8 @@ Tilt: an existing image and version might be specified in the Velero deployment
|
|||
**allowed_contexts** (Array, default=[]): A list of kubeconfig contexts Tilt is allowed to use. See the Tilt documentation on
|
||||
*[allow_k8s_contexts](https://docs.tilt.dev/api.html#api.allow_k8s_contexts) for more details. Note: Kind is automatically allowed.
|
||||
|
||||
**enable_restic** (Bool, default=false): Indicate whether to deploy the restic Daemonset. If set to `true`, Tilt will look for a `velero/tilt-resources/restic.yaml` file
|
||||
containing the configuration of the Velero restic DaemonSet.
|
||||
**use_node_agent** (Bool, default=false): Indicate whether to deploy the node-agent Daemonset. If set to `true`, Tilt will look for a `velero/tilt-resources/node-agent.yaml` file
|
||||
containing the configuration of the Velero node-agent DaemonSet.
|
||||
|
||||
**create_backup_locations** (Bool, default=false): Indicate whether to create one or more backup storage locations. If set to `true`, Tilt will look for a `velero/tilt-resources/velero_v1_backupstoragelocation.yaml` file
|
||||
containing at least one configuration for a Velero backup storage location.
|
||||
|
|
@ -97,7 +97,7 @@ containing at least one configuration for a Velero backup storage location.
|
|||
### Create Kubernetes resource files to deploy
|
||||
All needed Kubernetes resource files are provided as ready to use samples in the `velero/tilt-resources/examples` directory. You only have to move them to the `velero/tilt-resources` level.
|
||||
|
||||
Because the Velero Kubernetes deployment as well as the restic DaemonSet contain the configuration
|
||||
Because the Velero Kubernetes deployment as well as the node-agent DaemonSet contain the configuration
|
||||
for any plugin to be used, files for these resources are expected to be provided by the user so you may choose
|
||||
which provider plugin to load as a init container. Currently, the sample files provided are configured with all the
|
||||
plugins supported by Velero, feel free to remove any of them as needed.
|
||||
|
|
|
|||
|
|
@ -148,9 +148,9 @@ Follow the below troubleshooting steps to confirm that Velero is using the corre
|
|||
]
|
||||
```
|
||||
|
||||
If [restic-integration][3] is enabled, then, confirm that the restic daemonset is also mounting the `cloud-credentials` secret.
|
||||
If [File System Backup][3] is enabled, then, confirm that the node-agent daemonset is also mounting the `cloud-credentials` secret.
|
||||
```bash
|
||||
$ kubectl -n velero get ds restic -ojson |jq .spec.template.spec.containers[0].volumeMounts
|
||||
$ kubectl -n velero get ds node-agent -ojson |jq .spec.template.spec.containers[0].volumeMounts
|
||||
[
|
||||
{
|
||||
"mountPath": "/host_pods",
|
||||
|
|
@ -217,7 +217,7 @@ Follow the below troubleshooting steps to confirm that Velero is using the corre
|
|||
|
||||
[1]: debugging-restores.md
|
||||
[2]: debugging-install.md
|
||||
[3]: restic.md
|
||||
[3]: file-system-backup.md
|
||||
[4]: https://github.com/vmware-tanzu/velero/issues
|
||||
[5]: https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
|
||||
[6]: https://github.com/vmware-tanzu/helm-charts/blob/main/charts/velero
|
||||
|
|
|
|||
|
|
@ -21,12 +21,12 @@ velero install \
|
|||
--velero-pod-mem-request <MEMORY_REQUEST> \
|
||||
--velero-pod-cpu-limit <CPU_LIMIT> \
|
||||
--velero-pod-mem-limit <MEMORY_LIMIT> \
|
||||
[--use-restic] \
|
||||
[--default-volumes-to-restic] \
|
||||
[--restic-pod-cpu-request <CPU_REQUEST>] \
|
||||
[--restic-pod-mem-request <MEMORY_REQUEST>] \
|
||||
[--restic-pod-cpu-limit <CPU_LIMIT>] \
|
||||
[--restic-pod-mem-limit <MEMORY_LIMIT>]
|
||||
[--use-node-agent] \
|
||||
[--default-volumes-to-fs-backup] \
|
||||
[--node-agent-pod-cpu-request <CPU_REQUEST>] \
|
||||
[--node-agent-pod-mem-request <MEMORY_REQUEST>] \
|
||||
[--node-agent-pod-cpu-limit <CPU_LIMIT>] \
|
||||
[--node-agent-pod-mem-limit <MEMORY_LIMIT>]
|
||||
```
|
||||
|
||||
The values for the resource requests and limits flags follow the same format as [Kubernetes resource requirements][3]
|
||||
|
|
@ -39,7 +39,7 @@ This section provides examples that serve as a starting point for more customize
|
|||
```bash
|
||||
velero install --provider gcp --plugins velero/velero-plugin-for-gcp:v1.0.0 --bucket mybucket --secret-file ./gcp-service-account.json
|
||||
|
||||
velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.0.0 --bucket backups --provider aws --secret-file ./aws-iam-creds --backup-location-config region=us-east-2 --snapshot-location-config region=us-east-2 --use-restic
|
||||
velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.0.0 --bucket backups --provider aws --secret-file ./aws-iam-creds --backup-location-config region=us-east-2 --snapshot-location-config region=us-east-2 --use-node-agent
|
||||
|
||||
velero install --provider azure --plugins velero/velero-plugin-for-microsoft-azure:v1.0.0 --bucket $BLOB_CONTAINER --secret-file ./credentials-velero --backup-location-config resourceGroup=$AZURE_BACKUP_RESOURCE_GROUP,storageAccount=$AZURE_STORAGE_ACCOUNT_ID[,subscriptionId=$AZURE_BACKUP_SUBSCRIPTION_ID] --snapshot-location-config apiTimeout=<YOUR_TIMEOUT>[,resourceGroup=$AZURE_BACKUP_RESOURCE_GROUP,subscriptionId=$AZURE_BACKUP_SUBSCRIPTION_ID]
|
||||
```
|
||||
|
|
|
|||
|
|
@ -70,10 +70,4 @@ Here you will find external resources about Velero, such as videos, podcasts, an
|
|||
* [Cormac Hogan has written a series of blog posts on Velero](https://cormachogan.com/?s=velero)
|
||||
|
||||
|
||||
* [Backup and Restore MariaDB Galera Deployments on Kubernetes - by Vikram Vaswani](https://docs.bitnami.com/tutorials/backup-restore-data-mariadb-galera-kubernetes/)
|
||||
|
||||
|
||||
* Two great blog posts by community member Imran Pochi:
|
||||
* [Backup and Restore of Kubernetes Applications using Heptio’s Velero with Restic and Rook-Ceph as the storage provider](https://blog.kubernauts.io/backup-and-restore-of-kubernetes-applications-using-heptios-velero-with-restic-and-rook-ceph-as-2e8df15b1487)
|
||||
* [Backup and Restore PVCs using Velero with restic and OpenEBS from Baremetal cluster to AWS
|
||||
](https://blog.kubernauts.io/backup-and-restore-pvcs-using-velero-with-restic-and-openebs-from-baremetal-cluster-to-aws-d3ac54386109)
|
||||
* [Backup and Restore MariaDB Galera Deployments on Kubernetes - by Vikram Vaswani](https://docs.bitnami.com/tutorials/backup-restore-data-mariadb-galera-kubernetes/)
|
||||
Loading…
Reference in New Issue