Merge pull request #45 from jrnt30/snapshot-restore-defaults

Snapshot and restore volumes by default
pull/54/merge
Andy Goldstein 2017-08-22 09:08:03 -04:00 committed by GitHub
commit 3ca085eb58
9 changed files with 13 additions and 18 deletions

View File

@ -144,7 +144,7 @@ As mentioned before, Ark runs in two different modes:
* **Ark server**: Runs all of the Ark controllers. Each controller watches its respective custom resource for API operations, performs validation, and handles the majority of the cloud API logic (e.g. interfacing with object storage and persistent volumes).
Looking at a specific example--an `ark backup create test-backup --snapshot-volumes` command triggers the following operations:
Looking at a specific example--an `ark backup create test-backup` command triggers the following operations:
![19]
@ -156,7 +156,7 @@ Looking at a specific example--an `ark backup create test-backup --snapshot-volu
4. Once the data has been aggregated, the `BackupController` makes a call to the object storage service (e.g. Amazon S3) to upload the backup file.
5. If the `--snapshot-volumes` flag is specified, Ark also makes disk snapshots of any persistent volumes, using the appropriate cloud service API.
5. By default, Ark also makes disk snapshots of any persistent volumes, using the appropriate cloud service API. (This can be disabled via the option `--snapshot-volumes=false`)
## Further documentation

View File

@ -23,7 +23,7 @@ ark backup create NAME
-o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'.
-l, --selector labelSelector only back up resources matching this label selector (default <none>)
--show-labels show labels in the last column
--snapshot-volumes take snapshots of PersistentVolumes as part of the backup
--snapshot-volumes take snapshots of PersistentVolumes as part of the backup (default true)
--ttl duration how long before the backup can be garbage collected (default 24h0m0s)
```

View File

@ -19,7 +19,7 @@ ark restore create BACKUP
--namespace-mappings mapStringString namespace mappings from name in the backup to desired restored name in the form src1:dst1,src2:dst2,...
--namespaces stringArray comma-separated list of namespaces to restore
-o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'.
--restore-volumes whether to restore volumes from snapshots
--restore-volumes whether to restore volumes from snapshots (default true)
-l, --selector labelSelector only restore resources matching this label selector (default <none>)
--show-labels show labels in the last column
```

View File

@ -24,7 +24,7 @@ ark schedule create NAME
--schedule string a cron expression specifying a recurring schedule for this backup to run
-l, --selector labelSelector only back up resources matching this label selector (default <none>)
--show-labels show labels in the last column
--snapshot-volumes take snapshots of PersistentVolumes as part of the backup
--snapshot-volumes take snapshots of PersistentVolumes as part of the backup (default true)
--ttl duration how long before the backup can be garbage collected (default 24h0m0s)
```

View File

@ -311,12 +311,6 @@ ark restore create nginx-backup
> NOTE: For Azure, your Kubernetes cluster needs to be version 1.7.2+ in order to support PV snapshotting of its managed disks.
Label a node so that all nginx pods end up on the same machine (avoiding PV binding issues):
```
nginx_node_name=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')
kubectl label nodes $nginx_node_name app=nginx
```
Start the sample nginx app:
```
kubectl apply -f examples/nginx-app/with-pv.yaml
@ -329,7 +323,7 @@ kubectl label pv $nginx_pv_name app=nginx
```
Now create a backup with PV snapshotting:
```
ark backup create nginx-backup --selector app=nginx --snapshot-volumes
ark backup create nginx-backup --selector app=nginx
```
Simulate a disaster:
```
@ -340,7 +334,7 @@ Because the default [reclaim policy][19] for dynamically-provisioned PVs is "Del
Now restore your lost resources:
```
ark restore create nginx-backup --restore-volumes
ark restore create nginx-backup
```
[0]: /README.md#quickstart
@ -365,3 +359,4 @@ ark restore create nginx-backup --restore-volumes
[19]: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming
[20]: /CHANGELOG.md
[21]: /docs/build-from-scratch.md

View File

@ -35,7 +35,7 @@ Heptio Ark can help you port your resources from one cluster to another, as long
1. *(Cluster 1)* Assuming you haven't already been checkpointing your data with the Ark `schedule` operation, you need to first back up your entire cluster (replacing `<BACKUP-NAME>` as desired):
```
ark backup create <BACKUP-NAME> --snapshot-volumes
ark backup create <BACKUP-NAME>
```
The default TTL is 24 hours; you can use the `--ttl` flag to change this as necessary.
@ -45,7 +45,7 @@ Heptio Ark can help you port your resources from one cluster to another, as long
4. *(Cluster 2)* Once you have confirmed that the right Backup (`<BACKUP-NAME>`) is now present, you can restore everything with:
```
ark restore create <BACKUP-NAME> --restore-volumes
ark restore create <BACKUP-NAME>
```
[0]: #disaster-recovery

View File

@ -43,7 +43,7 @@ metadata:
name: nginx-deployment
namespace: nginx-example
spec:
replicas: 2
replicas: 1
template:
metadata:
labels:
@ -62,8 +62,6 @@ spec:
- mountPath: "/var/log/nginx"
name: nginx-logs
readOnly: false
nodeSelector:
app: nginx
---
apiVersion: v1

View File

@ -70,6 +70,7 @@ func NewCreateOptions() *CreateOptions {
TTL: 24 * time.Hour,
IncludeNamespaces: flag.NewStringArray("*"),
Labels: flag.NewMap(),
SnapshotVolumes: true,
}
}

View File

@ -66,6 +66,7 @@ func NewCreateOptions() *CreateOptions {
return &CreateOptions{
Labels: flag.NewMap(),
NamespaceMappings: flag.NewMap().WithEntryDelimiter(",").WithKeyValueDelimiter(":"),
RestoreVolumes: true,
}
}