Restauration on Zwindler's Reflection

Sauvegarder son Kubernetes avec Velero (ex Ark)

Mon, 02 Aug 2021 06:15:00 +0000

Contexte

J’ai écris cet article / tuto en janvier 2019 sans jamais le terminer / mettre en forme. A l’époque, Heptio était en train de se faire racheter par VMware. Au moment où j’allais le poster, VMware a fait quelques modifications dans le tool, notamment en changeant le nom de Ark vers Velero et en l’intégrant à Tanzu (le Kubernetes de VMware).

Idéalement, j’aurais donc aimé réécrire l’article en remettant tout à jour, les noms, les lignes de commandes, etc. Sauf que je ne l’ai jamais fait. Et aujourd’hui, je ne travaille plus sur des clusters Kubernetes avec des workloads majoritairement Stateful et préfère l’approche Déclarative (type FluxCD) dans l’hypothèse où j’aurais un énorme crash à gérer plutôt que de tenter une restauration, avec tous les effets de bords et les risques que ça implique.

Cependant, plutôt que de mettre cet article « presque fini » à la corbeille, je prend donc le parti de le poster « tel quel », avec tous les défauts qu’il pourra avoir (notamment si certaines parties sont outdated). Le concept général lui, restera le même.

Pour illustrer le propos, j’avais déployé un cluster AKS mais ça marche bien évidemment avec n’importe quel cluster Kubernetes.

Générer le cluster K8s AKS

az login
az group create --name myownkubernetescluster --location westeurope \
--subscription "Visual Studio Professional"
az aks create --resource-group myownkubernetescluster --name myawesomeakscluster \
--node-count 3 --enable-addons monitoring --node-vm-size Standard_B2s \
--kubernetes-version 1.10.9 --ssh-key-value ~/.ssh/dgermain_never_expire_rsa_openssl2.pub \
--subscription "Visual Studio Professional"
az aks get-credentials --resource-group myownkubernetescluster --name myawesomeakscluster \
--subscription "Visual Studio Professional"

Éventuellement ajouter les droits pour le dashboard

kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard
az aks browse --resource-group myownkubernetescluster --name myawesomecluster

Sauvegarde / restauration avec Velero

Information sur Velero (Ark Heptio) github.com/vmware-tanzu/velero

Comme on est sur Azure dans mon exemple :

github.com/vmware-tanzu/velero-plugin-for-microsoft-azure#setup

On commencer par créer un ressource group spécifique aux backups (pour ne pas tout perdre si le ressource group est supprimé)

AZURE_BACKUP_RESOURCE_GROUP=arkbackups
az group create -n $AZURE_BACKUP_RESOURCE_GROUP --location westeurope \
--subscription "Visual Studio Professional"
AZURE_STORAGE_ACCOUNT_ID="ark$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"
az storage account create \
--name $AZURE_STORAGE_ACCOUNT_ID \
--resource-group $AZURE_BACKUP_RESOURCE_GROUP \
--sku Standard_GRS \
--encryption-services blob \
--https-only true \
--kind BlobStorage \
--access-tier Hot \
--location westeurope \
--subscription "Visual Studio Professional"
az storage container create -n arkblob --public-access off \
--account-name $AZURE_STORAGE_ACCOUNT_ID --subscription "Visual Studio Professional"

Récupérer le groupe de ressource du cluster K8s

az group list --query '[].{ ResourceGroup: name, Location:location }' --subscription "Visual Studio Professional"
[...]
{
"Location": "westeurope",
"ResourceGroup": "MC_myownkubernetescluster_myawesomeakscluster_westeurope"
},
{
"Location": "westeurope",
"ResourceGroup": "myownkubernetescluster"
}

Dans le cas d’AKS, il s’agit bien de choisir le groupe qui contient les VMs (MC_myownkubernetescluster_myawesomeakscluster_westeurope), et pas celui que vous avez créé en début de procédure (myownkubernetescluster) qui ne contient que l’objet « Kubernetes service ».

AZURE_RESOURCE_GROUP=MC_myownkubernetescluster_myawesomeakscluster_westeurope

Créer un « Service principal » (compte de service dans Azure). Ne pas oublier de stocker le secret (contenu de la variable AZURE_CLIENT_SECRET) car on y aura plus accès a posteriori.

AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "myarkserviceprincipal" --role "Contributor" --query 'password' -o tsv`
AZURE_CLIENT_ID=`az ad sp list --display-name "myarkserviceprincipal" --query '[0].appId' -o tsv`

Récupérer les sources

Dans mon cas, la dernière version disponible est la v1.6.2, et j’ai besoin des la version linux amd64

mkdir velero && cd velero
wget https://github.com/vmware-tanzu/velero/releases/download/v1.6.2/velero-v1.6.2-linux-amd64.tar.gz
tar -xzf velero-v1.6.2-linux-amd64.tar.gz

Créer un namespace et un service provider (différents de ceux par défaut)

Quelque soit le cloud provider, il faut modifier le fichier config/common/00-prereqs.yaml

Comme indiqué dans la documentation dédiée, ce fichier contient la plupart des informations génériques, notamment, les définitions (CRD pour les backups/restores Ark), le namespace, le service account et les rôles (RBAC).

Dans notre cas, on doit donc modifier le fichier config/common/00-prereqs.yaml pour qu’il créé un autre namespace, qu’on appellera « backup » pour faire original;
On va aussi modifier le nom du service account pour qu’il colle à celui du Service Principal azure (pas obligatoire, mais c’est pour rester cohérent) et surtout son namespace.

vi config/common/00-prereqs.yaml
[...]
---
apiVersion: v1
kind: Namespace
metadata:
name: backup
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: myarkserviceprincipal
namespace: backup
labels:
component: ark
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: ark
labels:
component: ark
subjects:
- kind: ServiceAccount
namespace: backup
name: myarkserviceprincipal
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io

Ensuite, il faut également modifier les spécifiques à notre cloud provider (ici Azure), en particulier le namespace, mais aussi nos informations de connexion à notre blob

Dans le déploiement, changer le namespace et le serviceAccountName

vi config/azure/00-ark-deployment.yaml
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
namespace: backup
name: ark
[...]
spec:
restartPolicy: Always
serviceAccountName: myarkserviceprincipal
[...]

vi config/azure/05-ark-backupstoragelocation.yaml
---
apiVersion: ark.heptio.com/v1
kind: BackupStorageLocation
metadata:
name: default
namespace: backup
spec:
provider: azure
objectStorage:
bucket: arkblob
config:
resourceGroup: arkbackups
storageAccount: arkANDTHEUUID
vi config/azure/06-ark-volumesnapshotlocation.yaml
---
apiVersion: ark.heptio.com/v1
kind: VolumeSnapshotLocation
metadata:
name: azure-default
namespace: backup
spec:
provider: azure
config:
apiTimeout: 30s
resourceGroup: ark-EUW-sandbox-RG

Créer les objets sur le cluster Kubernetes sur Azure

kubectl --context=myawesomeakscluster apply -f config/common/00-prereqs.yaml
customresourcedefinition.apiextensions.k8s.io/backups.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/schedules.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/restores.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/downloadrequests.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/deletebackuprequests.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/podvolumebackups.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/podvolumerestores.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/resticrepositories.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/backupstoragelocations.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/volumesnapshotlocations.ark.heptio.com created
namespace/backup created
serviceaccount/arkeuwsandboxsp created
clusterrolebinding.rbac.authorization.k8s.io/ark created
kubectl --context=myawesomeakscluster apply -f config/azure/
deployment.apps/ark created
backupstoragelocation.ark.heptio.com/default created
volumesnapshotlocation.ark.heptio.com/azure-default created
daemonset.apps/restic created

A noter : avant le premier appel de ark, sur chaque machine, il faudra spécifier dans quel namespace est ark sur notre cluster K8s.

./ark client config set namespace=backup

Créer le secret du service provider

#AZURE_RESOURCE_GROUP=MC_myownkubernetescluster_myawesomeakscluster_westeurope
AZURE_SUBSCRIPTION_ID=d717105a-ac1d-457c-8ef8-7467aa90df5c
AZURE_TENANT_ID=15eb2494-5298-4347-81a3-e2d3c08a0f82
AZURE_CLIENT_ID=f44ae340-97a2-4d54-bdc5-c4d7b2a49a2a
AZURE_CLIENT_SECRET=r+VGoBqOwraH9uVdk/sED3Ezdb7bIZI1xjvZyyvmnzM=
kubectl --context=myawesomeakscluster --namespace=backup create secret generic ark-azure-credentials \
--from-literal AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID} \
--from-literal AZURE_TENANT_ID=${AZURE_TENANT_ID} \
--from-literal AZURE_CLIENT_ID=${AZURE_CLIENT_ID} \
--from-literal AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET} \
--from-literal AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
secret/ark-azure-credentials created

Créer des données dans le cluster pour vérifier le fonctionnement

kubectl create ns testrestore
namespace/testrestore created
kubectl run pod ubuntu --image=ubuntu --namespace=testrestore
deployment.apps/pod created
kubectl --namespace=testrestore get all
NAME READY STATUS RESTARTS AGE
pod/pod-5945cc9b88-sq8c8 0/1 RunContainerError 1 14s
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/pod 1 1 1 0 14s
NAME DESIRED CURRENT READY AGE
replicaset.apps/pod-5945cc9b88 1 1 0 14s

Créer une backup

./ark backup create $(date +"%Y%m%d-%H%M")
Backup request "20190109-1553" submitted successfully.
Run `ark backup describe 20190109-1553` or `ark backup logs 20190109-1553` for more details.
./ark backup describe 09-01-2019
Name: 09-01-2019
Namespace: backup
Labels:
Annotations:
Phase: New
Namespaces:
Included: *
Excluded:
Resources:
Included: *
Excluded:
Cluster-scoped: auto
Label selector:
Storage Location:
Snapshot PVs: auto
TTL: 720h0m0s
Hooks:
Backup Format Version: 0
Started: <n/a>
Completed: <n/a>
Expiration: 0001-01-01 00:00:00 +0000 UTC
Validation errors:
Persistent Volumes:

Restaurer une backup

kubectl --namespace=testrestore delete ns testrestore
namespace "testrestore" deleted
./ark backup get
NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
20190109-1553 Completed 2019-01-02 14:30:17 +0100 CET 23d default
./ark restore create restore-01 --from-backup 20190109-1553
Restore request "restore-01" submitted successfully.
Run `ark restore describe restore-01` or `ark restore logs restore-01` for more details.

Gérez vos sauvegardes ElasticSearch avec Curator

Tue, 11 Dec 2018 12:45:39 +0000

Curator et Elasticsearch

Il y a quelques mois, j’ai écris un article pour parler de mon expérience « supprime tes données dans ton cluster Elasticsearch par erreur ». Et par conséquent, de la sauvegarde que j’avais mis en place pour éviter de se retrouver sans rien en cas de récidive ;-).

Le moins qu’on puisse dire, c’est que l’utilisation des API pour une opération aussi régulière qu’une sauvegarde (ou la suppression des vieux index, par exemple) est quelque chose d’assez lourd à mettre en place.

Un des lecteurs avait pris le temps de me conseiller un outil fourni par les gens de chez Elastic, et qui permet de gérer plus simplement ces tâches fastidieuses : Curator.

Prérequis côté serveur

J’avais donc dis que je regarderai et j’ai donc profité d’un de mes clusters ElasticSearch sur Kubernetes pour tester l’outil.

La première chose à faire est donc de récupérer l’adresse IP (ou le nom DNS) qui nous permet d’accéder à l’API web de notre cluster ElasticSearch. Pour rester cohérent avec l’exemple, je vais dérouler la procédure de mise en place d’une sauvegarde avec Curator dans un cluster Kubernetes qui contient un cluster ElasticSearch existant (ça ne complique pas beaucoup). Mais dans tout les cas il vous faudra une adresse ;-).

kubectl --context=andromeda --namespace=elastic get svc elasticsearch
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
elasticsearch ClusterIP 10.10.10.15 9200/TCP,9300/TCP 115d

En se connectant dans le container Elastic, je peux regarder comment est configuré la base, et en particulier les destinations physiques « repo ».

kubectl --context=andromeda --namespace=elastic exec -it docker-elasticsearch-0 /bin/bash
cat /opt/elasticsearch/config/elasticsearch.yml
[...]
path:
data: ${ELASTICSEARTCH_DATA_DIR}/data
logs: ${ELASTICSEARTCH_DATA_DIR}/logs
repo: ${REPO_LOCATIONS}
[...]

Dans le cas d’ElasticSearch en tant que container Docker, il existe dans l’image Docker officielle une variable REPO_LOCATIONS. Dans mon cas, j’ai donc modifié la configuration de mon déploiement pour spécifier à ElasticSearch où trouver les variables.

[...]
- env:
- name: REPO_LOCATIONS
value: '["/data/bkp"]'
[...]

Pour ceux qui n’utilisent pas Elasticsearch en tant que cluster Docker (si vous l’avez installé avec un de mes playbooks Ansible par exemple), vous pouvez éditer le fichier de configuration et ajouter les lignes suivantes (et vous assurer que le chemin existe effectivement) :

sudo vim /etc/elasticsearch/elasticsearch.yml
[...]
path:
repo: ["/my/backup/directory/path"]
[...]

Redémarrer ElasticSearch pour prise en compte (ou deletez le pod, niark niark niark). Notre base ElasticSearch sait maintenant où déposer les futures sauvegardes.

Prérequis côté client

Lancer un curl sur l’adresse IP que vous avez collecter au début du tuto, pour voir si on arrive à lister les indices présents.

Dans mon cas, je lance un container Ubuntu directement dans le cluster K8s pour faire simple.

kubectl --context=andromeda run my-shell --rm -i --tty --image ubuntu -- bash
#install prerequisites for curl
apt-get update
apt-get -y install curl
#do the actual curl
curl -X GET "10.10.10.15:9200/_cat/indices?v"
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open awesomeapp-health-2018.11.30 6VrEZk-XTGm3eeKJEzDZnA 5 1 17054 0 2mb 2mb
[...]

OK ! On a bien accès à l’API. On peut maintenant configurer la variable d’environnement REPO_LOCATIONS

curl -XPUT 'http://10.10.10.15:9200/_snapshot/svg' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "/data/bkp",
"compress": true
}
}'

Cette commande devrait vous renvoyer ceci :

{"acknowledged":true}

Et maintenant ?

Cette partie du tuto était identique (à Kubernetes près) au tutoriel précédent. Maintenant, ça diffère.

On va installer Curator, mais pas via le gestionnaire de package du système. En effet, si vous avez une version récente d’ElasticSearch et que vous vous contentez d’APT, vous risquez d’obtenir l’erreur suivante :

apt-get install elasticsearch-curator
curator_cli show_indices
elasticsearch.exceptions.ElasticsearchException: Unable to create client connection to Elasticsearch. Error: Elasticsearch version 6.3.0 incompatible with this version of Curator (5.2.0)

La version conseillée par Elastic est l’utilisation du gestionnaire de package Python (pip) :

apt-get update
apt-get -y install curl python
curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python get-pip.py --force-reinstall
pip install elasticsearch-curator --user

Dans ce tutoriel, on va commencer par utiliser la CLI de Curator. Mais il faut savoir qu’il existe aussi une version qui permet de jouer des scenarii prédéfinis (les Actions). Du coup, il est logique que tout la partie connexion et authentification soit gérée par un fichier de configuration. Malheureusement, cette partie n’est pas super bien documentée si on se contente de la doc d’install (il faut fouiller un peu). Dans les grandes lignes, voilà ce qu’il faut faire :

mkdir ~/.curator
cat > ~/.curator/curator.yml << EOF
client:
hosts: 10.10.10.15
port: 9200
url_prefix:
use_ssl: False
certificate:
client_cert:
client_key:
ssl_no_validate: False
http_auth:
timeout: 30
master_only: False
logging:
loglevel: INFO
logfile: /data
logformat: default
blacklist: ['elasticsearch', 'urllib3']
EOF

Ici, j’ai juste ajouté mon IP et mon port de connexion à l’API, mais on peut donc aussi configurer pas mal de choses en plus.

Curator maintenant configuré, on peut tester la même commande qu’avec le cURL pour lister les indices.

/root/.local/bin/curator_cli show_indices
awesomeapp-health-2018.11.12
awesomeapp-health-2018.11.13
awesomeapp-health-2018.11.14
[...]

Création d’un snapshot

Maintenant qu’on a Curator qui peut se connecter à ElasticSearch, on va enfin pouvoir lancer notre sauvegarde, via la feature des snapshots ! (Plus d’info sur les filtres, vous pouvez aller sur la page de documentation officielle)

root/.local/bin/curator_cli snapshot --repository svg --filter_list '{"filtertype":"none"}'

La commande devrait prendre un certain temps, en particulier si vous avez beaucoup de données. Une fois qu’elle a rendu la main, vérifiez que le snapshot existe, avec la CLI, et en allant voir le contenu du dossier configuré précédemment.

root/.local/bin/curator_cli show_snapshots --repository svg
curator-20181204095300
ll /data/bck
total 36
drwxr-xr-x 3 elasticsearch elasticsearch 4096 Dec 4 09:54 ./
drwxr-xr-x 6 elasticsearch elasticsearch 4096 Dec 4 09:47 ../
-rw-r--r-- 1 elasticsearch elasticsearch 29 Dec 4 09:54 incompatible-snapshots
-rw-r--r-- 1 elasticsearch elasticsearch 5522 Dec 4 09:54 index-0
-rw-r--r-- 1 elasticsearch elasticsearch 8 Dec 4 09:54 index.latest
drwxr-xr-x 56 elasticsearch elasticsearch 4096 Dec 4 09:53 indices/
-rw-r--r-- 1 elasticsearch elasticsearch 103 Dec 4 09:53 meta-yMBl9IsPRYGCitWqGjxh2Q.dat
-rw-r--r-- 1 elasticsearch elasticsearch 470 Dec 4 09:54 snap-yMBl9IsPRYGCitWqGjxh2Q.dat

Je suis expert en sauvegarde moi, pas en restauration…

True story

Bon, sauvegarder c’est bien, restaurer c’est mieux ! Il existe bien évidemment une commande restore pour ça ;)

root/.local/bin/curator_cli restore --repository svg --name curator-20181204095300 --filter_list '{"filtertype":"none"}'

Et après !

Clairement, on ne va pas se contenter de ça. C’est déjà mieux que précédemment avec les appels d’API, mais on peut faire encore mieux. Déjà, si vous avez fait attention, j’ai teasé qu’on pouvait gérer les indices (et ainsi virer les plus vieux) avec Curator. C’est clairement un usecase hyper sympa de l’outil.

Ensuite, j’ai également teasé la possibilité de gérer des tâches en mode batch, avec les actions, qui sont des fichiers de définition simple de vos actions à faire avec Curator. Il y aura bien entendu des articles à suivre pour en apprendre plus ;-)

Ressources additionnelles

Sauvegarder et restaurer des index dans Elasticsearch

Wed, 04 Jul 2018 11:45:55 +0000

Un développeur s’est dit « J’ai BESOIN d’Elasticsearch ! »

Et ce qui devait arriver, arriva. Du jour au lendemain, vous n’avez pas eu le temps de dire « ouf » et vous avez déjà une base Elasticsearch à maintenir en production !

Dure vie des #Ops ;-)

On va apprendre comment sauvegarder et restaurer des données dans ELK

Cet article n’arrive pas par hasard. A la base je voulais faire un article sur l’utilisation d’ELK avec l’API REST. Mais en jouant avec les API (en voulant purger des données de manière ciblée), j’ai supprimé un mois complet de données.

S’il y a une chose que j’ai apprise avec ce blog, c’est qu’il faut toujours poster l’article sur la solution à un problème AVANT l’article où je parle du problème que j’ai eu. Certains lecteurs ont parfois un peu la tête en l’air, et mieux vaut avoir la solution sous le coude a priori. ;-)

Oops

Les snapshots

On ne peut pas dire que cette partie de la documentation d’Elastic soit hyper bien mise en avant. Ca fait partie de ces projets où la mise en place (regardez comme c’est facile à installer) et tellement mise en avant qu’on ne sait pas comment l’exploiter après.

Mais en insistant un peu on fini par tomber sur les snapshots, la feature qui va vous permettre de faire des dumps de vos données à un instant T.

Mise en place du dossier de snap

La première chose à faire est de configurer notre répertoire où on va déposer/récupérer nos fichiers snapshots. Assurez vous qu’Elasticsearch puisse lire/écrire dedans, bien entendu !

On commence par indiquer le chemin dans le fichier de configuration d’Elasticsearch (ici /svg)

vi /etc/elasticsearch/elasticsearch.yml
path.repo: ["/svg"]

On créé le dossier (ben oui) et on lui donne les droits qui vont bien.

mkdir /svg

Créer l’emplacement des snapshots

Maintenant que notre Elasticsearch est configuré, on peut créer un snapshot. Les interactions avec Elasticsearch se font exclusivement en API, donc on dégaine notre plus beau JSON avec cURL :

curl -XPUT 'http://localhost:9200/_snapshot/svg' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "/svg",
"compress": true
}
}'

Dans cet exemple, j’exécute la requête en local (localhost), mais vous pouvez bien entendu lancer l’instruction sur des hôtes distants.

Notez aussi que j’ai ajouté l’option compress, pour des raisons évidentes d’économies d’espace disque et que j’ai indiqué la location à /svg, qu’on a défini précédemment.

On vérifie que la commande a bien été prise en compte (à partir de maintenant je vais omettre la partie cURL et juste mettre la requête) :

GET /_snapshot/svg
{
"svg": {
"type": "fs",
"settings": {
"compress": "true",
"location": "/svg"
}
}
}

Ça y est, on a des sauvegardes ?

Non, pas encore tout à fait :-/

Maintenant que j’ai créé l’emplacement, je dois créer le snapshot :

PUT /_snapshot/svg/snapshot_1
{
"accepted": true
}

Maintenant c’est bon. On peut ensuite vérifier où on en est avec la requête suivante :

GET /_snapshot/svg/snapshot_1
{
"snapshots": [
{
"snapshot": "snapshot_1",
"uuid": "s38NGqRES1uZfiyHiRNJVQ",
"version_id": 5060299,
"version": "5.6.2",
"indices": [
"logstash-2017.06.29",
"logstash-2017.10.18",
[...]
"logstash-2017.09.10",
"logstash-2017.10.11",
"logstash-2017.10.09"
],
"state": "IN_PROGRESS",
"start_time": "2017-10-25T18:36:07.931Z",
"start_time_in_millis": 1508956567931,
"end_time": "1970-01-01T00:00:00.000Z",
"end_time_in_millis": 0,
"duration_in_millis": -1508956567931,
"failures": [],
"shards": {
"total": 0,
"failed": 0,
"successful": 0
}
}
]
}

Le retour affiche la liste des snapshots existants (ici seulement snapshot_1 puisque c’est notre premier). On voit l’ensemble des index (sous indices).

On remarque aussi que la variable state à IN_PROGRESS et dans shards, successful est à 0.

On peut surveiller l’avancement de notre snapshot avec la même commande, un peu plus tard. L’état est passé à SUCCESS.

GET /_snapshot/svg/snapshot_1
{
"snapshots": [
{
"snapshot": "snapshot_1",
"uuid": "s38NGqRES1uZfiyHiRNJVQ",
"version_id": 5060299,
"version": "5.6.2",
"indices": [
"logstash-2017.06.29",
"logstash-2017.10.18",
"logstash-2017.08.01",
"logstash-2017.09.23",
"logstash-2017.09.29",
"logstash-2017.07.11",
[...]
],
"state": "SUCCESS",
"start_time": "2017-10-25T18:36:07.931Z",
"start_time_in_millis": 1508956567931,
"end_time": "2017-10-25T18:46:14.231Z",
"end_time_in_millis": 1508957174231,
"duration_in_millis": 606300,
"failures": [],
"shards": {
"total": 621,
"failed": 0,
"successful": 621
}
}
]
}

Si vous utilisez Kibana avec votre Elasticsearch, vous pouvez aussi vous passer de cURL et utiliser le menu Admin dans Kibana.

Restauration

Maintenant qu’on a une sauvegarde, on est hyper contents :)

De tous les indices qu’on a sauvegarder, on peut en sélectionner un (ou plusieurs), et lancer une restauration !

On lancer la restauration avec une requête à l’API :

POST /_snapshot/svg/snapshot_1/_restore
{
"indices": "logstash-2017.10.21",
"ignore_unavailable": true,
"include_global_state": true
}

Et paf ! Ça ne marche pas !

En fait c’est normal. L’index en question est encore ouvert. Il faut le fermer pour le restaurer

However, an existing index can be only restored if it’s closed{.link} and has the same number of shards as the index in the snapshot. The restore operation automatically opens restored indices if they were closed and creates new indices if they didn’t exist in the cluster.

POST /logstash-2017.10.21/_close

Et maintenant on peut lancer notre restauration !

Si jamais on n’a pas envie de lancer la restauration des index un par un (ce qui peut être un peu long si vous en avez beaucoup à restaurer ;-p), on peut aussi utiliser des wildcard. Par exemple, si j’ai supprimé les index des 9 premiers jours du mois d’octobre :

POST /logstash-2017.10.0*/_close
POST /_snapshot/svg/snapshot_1/_restore
{
"indices": "logstash-2017.10.0*",
"ignore_unavailable": true,
"include_global_state": true
}

Une fois l’opération terminée, j’ai pu récupérer les index bêtement supprimés :

TADAAAAM

Bonus : C’est pas très industrialisé tout ça !

Comme le fait remarquer à très juste titre coom dans les commentaires, il existe un moyen officiel de gérer ça de façon plus industrielle => via curator.

Curator est un outil officiel d’elastic et il permet de faciliter l’administration de vos indices, et notamment la gestion des snapshots. La documentation contient également des exemples (notamment l’exemple de la gestion des snapshots justement).

Si j’ai le temps je ferai un petit article sur les capacités de Curator, qui sont nombreuses.

Sauvegardez vos ESXi 6.5 sans licence avec GhettoVCB

Tue, 09 Jan 2018 12:45:37 +0000

GhettoVCB, depuis VMware Infrastructure 3, toujours compatible !

En 2010, un de mes tout premiers articles sur ce blog parlait d’un script s’appelant GhettoVCB. Il permettait de réaliser des sauvegardes à chaud sur des ESXi, SANS vCenter. Et c’est là toute la nuance, car si toutes les solutions de sauvegardes d’entreprises savent aujourd’hui sauvegarder des machines virtuelles VMware, elles se basent toutes sur un API (historiquement VCB pour VMware Consolidated Backup).

Or, l’usage l’API de sauvegarde (VCB, puis VADP et maintenant VMware vSphere Storage APIs – Data Protection) est conditionnée à la présence d’une licence ! Impossible d’utiliser ces outils avec un ESXi « gratuit » (free).

What licensing is required to use VMware vSphere Storage APIs – Data Protection?
Data Protection APIs are included with all licensed vSphere editions.

Ce script (mis en ligne depuis 2008 !) se base directement sur les binaires présents sur l’OS, sans passer par l’API VCB. Il fait donc pratiquement la même chose, mais gratuitement. Inutile de vous dire que ce script est très populaire parmi les bidouilleurs au budget limités et souhaitant quand même faire des sauvegardes.

Je vous met aussi le lien vers le post historique.

Installation

Historiquement, en guise « d’installation », il fallait simplement copier le script dans le répertoire de son choix. Aujourd’hui, c’est un peu plus « propre » puisque l’auteur a mis à disposition un VIB qui permet d’installer sur l’ESXi via un package. Les sources ont été hébergées sur Github.

Télécharger le fichier depuis le Github (lien mort), puis le copier en SSH/SCP/SFTP dans /tmp. Se connecter en SSH et installer la VIB :

esxcli software vib install -v /tmp/ -f

Note : maintenant il faut le build soi même cf https://github.com/lamw/ghettoVCB/blob/master/build/README.md

Pas besoin de rebooter avec cette VIB (simple copie du script). E-Z.

Mise en place de la sauvegarde

La documentation n’a pas été reportée sur le Github malheureusement, mais elle est toujours disponible sur le site historique de la communauté VMware.

Dans l’exemple suivant, on va, configurer le datastore VMFS_BCK comme destination de notre sauvegarde, sélectionner les VMs qu’on souhaite sauvegarder, et planifier (enfin… crontab quoi) nos sauvegardes. Youhou !

Sauf erreur de ma part, la documentation n’indique pas les chemins des fichiers scripts et de configuration. Avant c’était plus simple, vous téléchargiez tout et vous le mettiez dans le dossier que vous vouliez. Maintenant, la VIB dépose le fichier de configuration principal, un template de sauvegarde et un autre de restauration dans /etc/ghettovcb/. Les scripts sont quant à eux installés dans /opt/ghettovcb/bin/.

Se connecter en SSH sur le serveur VMware concerné. Voici un exemple de configuration de sauvegarde :

cd /etc/ghettovcb/
vi ghettoVCB.conf
VM_BACKUP_VOLUME=/vmfs/volumes/VMFS_BCK/backup
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0
SNAPSHOT_TIMEOUT=15
EMAIL_ALERT=0
EMAIL_LOG=0
EMAIL_SERVER=[@IP]
EMAIL_SERVER_PORT=25
EMAIL_DELAY_INTERVAL=1
EMAIL_TO=ghettovcb@zwindler.fr
EMAIL_ERRORS_TO=
EMAIL_FROM=alert_ghettoVCB@zwindler.fr
WORKDIR_DEBUG=0
VM_SHUTDOWN_ORDER=
VM_STARTUP_ORDER=

Ce fichier va nous permettre de configurer toutes les valeurs « par défaut » lors de nos sauvegardes.

Pour éviter tout souci, vérifiez qu’il y a bien de l’espace disponible sur le datastore choisi et que le chemin existe ;-).

ls /vmfs/volumes/VMFS_BCK/backup

Chacune des valeurs contenues dans la configuration peuvent être surchargées par le fichier de sauvegarde que nous allons créer. Dans cet exemple je ne modifie rien mais là c’est à vous de voir ! Ici, j’ajoute simplement la VM à une liste des machines virtuelles à sauvegarder :

vi /etc/ghettovcb/vm_backup_list
ma_vm_a_sauvegarder

On commence par lancer le script à la main pour voir en live si ça fonctionne :

/opt/ghettovcb/bin/ghettoVCB.sh -f /etc/ghettovcb/vm_backup_list -g /etc/ghettovcb/ghettoVCB.conf

Une fois que le script rend la main, vérifier dans le dossier de destination que la sauvegarde s’est bien réalisée. Il devrait contenir un dossier daté du jour et tous les fichiers de la VM.

cd /vmfs/volumes/VMFS_BCK/backup

Pour faire simple, vous pouvez commencer par une sauvegarde toutes les semaines (dimanche minuit) :

crontab -e
#Sauvegarde hebdo des VMs critiques
00 0 * * 0 /opt/ghettovcb/bin/ghettoVCB.sh -f /etc/ghettovcb/vm_backup_list -g /etc/ghettovcb/ghettoVCB.conf

Restauration

Nous allons jouer ici le scénario d’une restauration (ma_vm_a_restaurer) située sur le datastore /vmfs/volumes/VMFS. Il faut donc :

Mettre de côté la machine HS
Trouver la sauvegarde que l’on souhaite restaurer
La restaurer à l’emplacement initial de la VM

Retirer la VM à restaurer de l’inventaire et garder une copie au cas où

vmware-cmd -s unregister ma_vm_a_restaurer
mv /vmfs/volumes/VMFS/ma_vm_a_restaurer /vmfs/volumes/VMFS/ma_vm_a_restaurer.ko

Retrouver la sauvegarde qu’on souhaite restaurer

cd /vmfs/volumes/VMFS_BCK/backup/ma_vm_a_restaurer
ls -l
drwxr-xr-x 1 root root 840 Sep 3 14:12 ma_vm_a_restaurer-2032-09-03_00-00-00

Réaliser la restauration en elle même

Ici, on fait une copie du template de restauration et on y modifie les variables comme le chemin souhaité et le datastore cible. On termine l’opération en exécutant le script ghettoVCB-restore.sh

cd /etc/ghettovcb/
cp ghettoVCB-restore_vm_restore_configuration_template ghettoVCB-restore_ma_vm_a_sauvegarder
vi ghettoVCB-restore_ma_vm_a_restaurer
/vmfs/volumes/VMFS_BCK/backup/ma_vm_a_restaurer/ma_vm_a_restaurer-2032-09-03_00-00-00;/vmfs/volumes/VMFS;3
/opt/ghettovcb/bin/ghettoVCB-restore.sh -c /etc/ghettovcb/ghettoVCB-restore_ma_vm_a_restaurer

Finaliser la restauration

Une fois la recopie de la sauvegarde terminée, la VM devrait réapparaitre (automatiquement) dans l’inventaire de votre serveur VMware (le script effectue le register_vm).

Démarrer la VM. Si tout a fonctionné, la VM devrait rester bloquée et c’est « normal ».

VMware va détecter qu’il y a eu une opération et vous posera la question pour savoir si c’est une copie ou déplacement. Même si dans la majorité des cas ça ne devrait pas avoir d’impact, il est préférable de répondre « I moved it »/ »Je l’ai déplacé ».

Dans le cas contraire, VMware modifiera une partie de la VM, notamment son adresse MAC, ce qui n’est pas forcément souhaitable dans le cadre d’une restauration. « I moved it » permet de garder la VM telle quelle.

Enjoy !