parent
486fc07e85
commit
809e01aaa9
|
@ -56,10 +56,10 @@ defaults:
|
|||
gh: https://github.com/vmware-tanzu/velero/tree/master
|
||||
layout: "docs"
|
||||
- scope:
|
||||
path: docs/v1.3.0-beta.1
|
||||
path: docs/v1.3.0-beta.2
|
||||
values:
|
||||
version: v1.3.0-beta.1
|
||||
gh: https://github.com/vmware-tanzu/velero/tree/v1.3.0-beta.1
|
||||
version: v1.3.0-beta.2
|
||||
gh: https://github.com/vmware-tanzu/velero/tree/v1.3.0-beta.2
|
||||
layout: "docs"
|
||||
- scope:
|
||||
path: docs/v1.2.0
|
||||
|
@ -160,7 +160,7 @@ versioning: true
|
|||
latest: v1.2.0
|
||||
versions:
|
||||
- master
|
||||
- v1.3.0-beta.1
|
||||
- v1.3.0-beta.2
|
||||
- v1.2.0
|
||||
- v1.1.0
|
||||
- v1.0.0
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
# that the navigation for older versions still work.
|
||||
|
||||
master: master-toc
|
||||
v1.3.0-beta.1: v1-3-0-beta-1-toc
|
||||
v1.3.0-beta.2: v1-3-0-beta-2-toc
|
||||
v1.2.0: v1-2-0-toc
|
||||
v1.1.0: v1-1-0-toc
|
||||
v1.0.0: v1-0-0-toc
|
||||
|
|
|
@ -1,23 +0,0 @@
|
|||
# Run in custom namespace
|
||||
|
||||
You can run Velero in any namespace.
|
||||
|
||||
First, ensure you've [downloaded & extracted the latest release][0].
|
||||
|
||||
Then, install Velero using the `--namespace` flag:
|
||||
|
||||
```bash
|
||||
velero install --bucket <YOUR_BUCKET> --provider <YOUR_PROVIDER> --namespace <YOUR_NAMESPACE>
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Specify the namespace in client commands
|
||||
|
||||
To specify the namespace for all Velero client commands, run:
|
||||
|
||||
```bash
|
||||
velero client config set namespace=<NAMESPACE_VALUE>
|
||||
```
|
||||
|
||||
[0]: basic-install.md#install-the-cli
|
|
@ -27,7 +27,7 @@ If you encounter issues, review the [troubleshooting docs][30], [file an issue][
|
|||
|
||||
## Contributing
|
||||
|
||||
If you are ready to jump in and test, add code, or help with documentation, follow the instructions on our [Start contributing](https://velero.io/docs/v1.3.0-beta.1/start-contributing/) documentation for guidance on how to setup Velero for development.
|
||||
If you are ready to jump in and test, add code, or help with documentation, follow the instructions on our [Start contributing](https://velero.io/docs/v1.3.0-beta.2/start-contributing/) documentation for guidance on how to setup Velero for development.
|
||||
|
||||
## Changelog
|
||||
|
|
@ -6,11 +6,13 @@ Here we list the API types that have some functionality that you can only config
|
|||
(hooks)
|
||||
|
||||
* [Backup][1]
|
||||
* [Schedule][2]
|
||||
* [BackupStorageLocation][3]
|
||||
* [VolumeSnapshotLocation][4]
|
||||
* [Restore][2]
|
||||
* [Schedule][3]
|
||||
* [BackupStorageLocation][4]
|
||||
* [VolumeSnapshotLocation][5]
|
||||
|
||||
[1]: backup.md
|
||||
[2]: schedule.md
|
||||
[3]: backupstoragelocation.md
|
||||
[4]: volumesnapshotlocation.md
|
||||
[2]: restore.md
|
||||
[3]: schedule.md
|
||||
[4]: backupstoragelocation.md
|
||||
[5]: volumesnapshotlocation.md
|
|
@ -0,0 +1,89 @@
|
|||
# Restore API Type
|
||||
|
||||
## Use
|
||||
|
||||
The `Restore` API type is used as a request for the Velero server to perform a Restore. Once created, the
|
||||
Velero Server immediately starts the Restore process.
|
||||
|
||||
## API GroupVersion
|
||||
|
||||
Restore belongs to the API group version `velero.io/v1`.
|
||||
|
||||
## Definition
|
||||
|
||||
Here is a sample `Restore` object with each of the fields documented:
|
||||
|
||||
```yaml
|
||||
# Standard Kubernetes API Version declaration. Required.
|
||||
apiVersion: velero.io/v1
|
||||
# Standard Kubernetes Kind declaration. Required.
|
||||
kind: Restore
|
||||
# Standard Kubernetes metadata. Required.
|
||||
metadata:
|
||||
# Restore name. May be any valid Kubernetes object name. Required.
|
||||
name: a-very-special-backup-0000111122223333
|
||||
# Restore namespace. Must be the namespace of the Velero server. Required.
|
||||
namespace: velero
|
||||
# Parameters about the restore. Required.
|
||||
spec:
|
||||
# BackupName is the unique name of the Velero backup to restore from.
|
||||
backupName: a-very-special-backup
|
||||
# Array of namespaces to include in the restore. If unspecified, all namespaces are included.
|
||||
# Optional.
|
||||
includedNamespaces:
|
||||
- '*'
|
||||
# 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')
|
||||
# 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')
|
||||
# or fully-qualified. Optional.
|
||||
excludedResources:
|
||||
- storageclasses.storage.k8s.io
|
||||
# Whether or not to include cluster-scoped resources. Valid values are true, false, and
|
||||
# null/unset. If true, all cluster-scoped resources are included (subject to included/excluded
|
||||
# resources and the label selector). If false, no cluster-scoped resources are included. If unset,
|
||||
# all cluster-scoped resources are included if and only if all namespaces are included and there are
|
||||
# no excluded namespaces. Otherwise, if there is at least one namespace specified in either
|
||||
# includedNamespaces or excludedNamespaces, then the only cluster-scoped resources that are backed
|
||||
# up are those associated with namespace-scoped resources included in the restore. For example, if a
|
||||
# PersistentVolumeClaim is included in the restore, its associated PersistentVolume (which is
|
||||
# cluster-scoped) would also be backed up.
|
||||
includeClusterResources: null
|
||||
# Individual objects must match this label selector to be included in the restore. Optional.
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
app: velero
|
||||
component: server
|
||||
# NamespaceMapping is a map of source namespace names to
|
||||
# target namespace names to restore into. Any source namespaces not
|
||||
# included in the map will be restored into namespaces of the same name.
|
||||
namespaceMapping:
|
||||
namespace-backup-from: namespace-to-restore-to
|
||||
# RestorePVs specifies whether to restore all included PVs
|
||||
# from snapshot (via the cloudprovider).
|
||||
restorePVs: true
|
||||
# ScheduleName is the unique name of the Velero schedule
|
||||
# to restore from. If specified, and BackupName is empty, Velero will
|
||||
# restore from the most recent successful backup created from this schedule.
|
||||
scheduleName: my-scheduled-backup-name
|
||||
# RestoreStatus captures the current status of a Velero restore. Users should not set any data here.
|
||||
status:
|
||||
# The current phase. Valid values are New, FailedValidation, InProgress, Completed, PartiallyFailed, Failed.
|
||||
phase: ""
|
||||
# An array of any validation errors encountered.
|
||||
validationErrors: null
|
||||
# Number of warnings that were logged by the restore.
|
||||
warnings: 2
|
||||
# Errors is a count of all error messages that were generated
|
||||
# during execution of the restore. The actual errors are stored in object
|
||||
# storage.
|
||||
errors: 0
|
||||
# FailureReason is an error that caused the entire restore
|
||||
# to fail.
|
||||
failureReason:
|
||||
|
||||
```
|
|
@ -52,7 +52,7 @@ 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/v1.3.0-beta.1/pkg/restic/mocks/restorer.go
|
||||
Example: if you want to change this mock: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/pkg/restic/mocks/restorer.go
|
||||
|
||||
Run:
|
||||
|
|
@ -241,5 +241,5 @@ After creating the Velero server in your cluster, try this example:
|
|||
|
||||
## Additional Reading
|
||||
|
||||
* [Official Velero Documentation](https://velero.io/docs/v1.3.0-beta.1/)
|
||||
* [Official Velero Documentation](https://velero.io/docs/v1.3.0-beta.2/)
|
||||
* [Oracle Cloud Infrastructure Documentation](https://docs.cloud.oracle.com/)
|
|
@ -87,5 +87,5 @@ Once parsed into a `[]string`, the features can then be registered using the `Ne
|
|||
Velero adds the `LD_LIBRARY_PATH` into the list of environment variables to provide the convenience for plugins that requires C libraries/extensions in the runtime.
|
||||
|
||||
[1]: https://github.com/vmware-tanzu/velero-plugin-example
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.1/pkg/plugin/logger.go
|
||||
[3]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.1/pkg/restore/restic_restore_action.go
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/pkg/plugin/logger.go
|
||||
[3]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/pkg/restore/restic_restore_action.go
|
|
@ -22,7 +22,7 @@ Examples of cases where Velero is useful:
|
|||
|
||||
Yes, with some exceptions. For example, when Velero restores pods it deletes the `nodeName` from the
|
||||
pod so that it can be scheduled onto a new node. You can see some more examples of the differences
|
||||
in [pod_action.go](https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.1/pkg/restore/pod_action.go)
|
||||
in [pod_action.go](https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/pkg/restore/pod_action.go)
|
||||
|
||||
## I'm using Velero in multiple clusters. Should I use the same bucket to store all of my backups?
|
||||
|
|
@ -77,5 +77,5 @@ velero backup logs nginx-hook-test | grep hookCommand
|
|||
|
||||
|
||||
[1]: api-types/backup.md
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.1/examples/nginx-app/with-pv.yaml
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/examples/nginx-app/with-pv.yaml
|
||||
[3]: cloud-common.md
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
@ -0,0 +1,19 @@
|
|||
# Run in a non-default namespace
|
||||
|
||||
The Velero installation and backups by default are run in the `velero` namespace. However, it is possible to use a different namespace.
|
||||
|
||||
### 1) Customize the namespace during install
|
||||
|
||||
Use the `--namespace` flag, in conjunction with the other flags in the `velero install` command (as shown in the [the Velero install instructions][0]). This will inform Velero where to install.
|
||||
|
||||
### 2) Customize the namespace for operational commands
|
||||
|
||||
To have namespace consistency, specify the namespace for all Velero operational commands to be the same as the namespace used to install Velero:
|
||||
|
||||
```bash
|
||||
velero client config set namespace=<NAMESPACE_VALUE>
|
||||
```
|
||||
|
||||
Alternatively, you may use the global `--namespace` flag with any operational command to tell Velero where to run.
|
||||
|
||||
[0]: basic-install.md#install-the-cli
|
|
@ -17,5 +17,5 @@ Please browse our list of resources, including a playlist of past online communi
|
|||
|
||||
If you are ready to jump in and test, add code, or help with documentation, please use the navigation on the left under `Contribute`.
|
||||
|
||||
[1]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.1/CODE_OF_CONDUCT.md
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.1/CONTRIBUTING.md
|
||||
[1]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/CODE_OF_CONDUCT.md
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/CONTRIBUTING.md
|
|
@ -18,7 +18,7 @@ Alternatively, for quickly loading the website, under the `velero/site/` directo
|
|||
bundle exec jekyll serve --livereload --future
|
||||
```
|
||||
|
||||
For more information on how to run the website locally, please see our [jekyll documentation](https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.1/site/README-JEKYLL.md).
|
||||
For more information on how to run the website locally, please see our [jekyll documentation](https://github.com/vmware-tanzu/velero/blob/v1.3.0-beta.2/site/README-JEKYLL.md).
|
||||
|
||||
## Adding a blog post
|
||||
|
Loading…
Reference in New Issue