From 2b82c96f267ddf2947ccbe9f2ecff98ea2cd61a8 Mon Sep 17 00:00:00 2001 From: Andy Goldstein Date: Tue, 10 Oct 2017 11:00:44 -0400 Subject: [PATCH] FAQ follow-up Signed-off-by: Andy Goldstein --- docs/faq.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/faq.md b/docs/faq.md index 3577b3018..bc6ec9399 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -2,12 +2,16 @@ ## When is it appropriate to use Ark instead of etcd's built in backup/restore? -Etcd's restore tooling is good for recovering from data loss in a single etcd cluster, but does not -support more sophisticated restores. If you only want to recover from data loss in a single etcd -cluster, you're likely better off using etcd's backup/restore tooling. +Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For +example, it is a good idea to take a backup of etcd prior to upgrading etcd istelf. For more +sophisticated management of your Kubernetes cluster backups and restores, we feel that Ark is +generally a better approach. It gives you the ability to throw away an unstable cluster and restore +your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up +and restoring etcd. Examples of cases where Ark is useful: +* you don't have access to etcd (e.g. you're running on GKE) * backing up both Kubernetes resources and persistent volume state * cluster migrations * backing up a subset of your Kubernetes resources