mirrors/velero
1
0
Fork 0
mirror of https://github.com/vmware-tanzu/velero.git synced 2026-01-08 06:15:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Amended documentation to clarify use of ttl flag

Browse Source 
Signed-off-by: Keith <keith.rochford@gmail.com>
This commit is contained in:
Keith
2020-04-06 13:55:27 +01:00
parent a65eff6fde
commit e4ccb00649
3 changed files with 11 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
site/docs/v1.3.2/disaster-case.md
View File

@@ -10,7 +10,7 @@ If you periodically back up your cluster's resources, you are able to return to
velero schedule create <SCHEDULE NAME> --schedule "0 7 * * *"
```
This creates a Backup object with the name `<SCHEDULE NAME>-<TIMESTAMP>`.
This creates a Backup object with the name `<SCHEDULE NAME>-<TIMESTAMP>`. 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. A disaster happens and you need to recreate your resources.
@@ -31,9 +31,11 @@ If you periodically back up your cluster's resources, you are able to return to
1. When ready, revert your backup storage location to read-write mode:
```bash
kubectl patch backupstoragelocation <STORAGE LOCATION NAME> \
```bash
kubectl patch backupstoragelocation <STORAGE LOCATION NAME> \
--namespace velero \
--type merge \
--patch '{"spec":{"accessMode":"ReadWrite"}}'
```
[1]: how-velero-works.md#set-a-backup-to-expire

4
site/docs/v1.3.2/how-velero-works.md
View File

@@ -57,13 +57,15 @@ For example, if the cluster being backed up has a `gizmos` resource in the `thin
## Set a backup to expire
When you create a backup, you can specify a TTL by adding the flag `--ttl <DURATION>`. If Velero sees that an existing backup resource is expired, it removes:
When you create a backup, you can specify a TTL (time to live) by adding the flag `--ttl <DURATION>`. If Velero sees that an existing backup resource is expired, it removes:
* The backup resource
* The backup file from cloud object storage
* 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.
## Object storage sync
Velero treats object storage as the source of truth. It continuously checks to see that the correct backup resources are always present. If there is a properly formatted backup file in the storage bucket, but no corresponding backup resource in the Kubernetes API, Velero synchronizes the information from object storage to Kubernetes.

4
site/docs/v1.3.2/migration-case.md
View File

@@ -10,7 +10,7 @@ Velero can help you port your resources from one cluster to another, as long as
velero backup create <BACKUP-NAME>
```
The default TTL is 30 days (720 hours); you can use the `--ttl` flag to change this as necessary.
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`.
@@ -46,3 +46,5 @@ Check that the second cluster is behaving as expected:
```
If you encounter issues, make sure that Velero is running in the same namespace in both clusters.
[1]: how-velero-works.md#set-a-backup-to-expire