Sauvegarde 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 !

Utiliser PowerCLI pour créer un template de VM VMware

Tue, 07 Mar 2017 13:00:52 +0000

VMware et PowerCLI

Ça fait un long moment que j’ai cet article dans les tiroirs et aujourd’hui je n’ai plus vraiment l’intention d’utiliser PowerCLI pour automatiser ce genre de choses.

Pour autant, il y a quelques années, on m’a demandé de réaliser une copie complète quotidienne d’une machine virtuelle donnée. N’ayant à l’époque qu’une vieille version de DataProtector (youpi…) sur site, je n’avais pas d’outil pour sauvegarder simplement une machine complète, et encore moins donner les moyens de la restaurer rapidement en cas de crash.

Ayant déjà bidouillé avec GhettoVCB, qui permet notamment de sauvegarder à chaud des machines virtuelles VMware même quand on a pas de vCenter, je savais qu’il y avait des possibilités.

Dans mon cas précis, il y avait un cluster vSphere avec un vCenter installé sur un serveur Windows (à l’ancienne). Et comme je souhaitais automatiser cette tâche de copie depuis le vCenter, je ne voulais pas utiliser le VIPerl. A ce moment là, Microsoft mettait en avant Powershell, ce qui incitait les éditeurs à fournir leurs modules compatibles. C’est ainsi que naquit PowerCLI.

A noter, dans le cas présent, il sera nécessaire d’avoir le vCenter car le module PowerShell PowerCLI se base sur la même API fournie par VMware que celle utilisée par VIPerl.

Quand on a un vCenter, on peut faire beaucoup de choses via l’API (et donc via PowerCLI). Le plus simple pour résoudre le problème posé était de déclencher chaque jour la création d’un clone ou d’un template. Et c’est donc ce que j’ai fais !

Bon… du coup, je n’ose pas vraiment parler de « sauvegarde » car il s’agit de tout sauf ça. Mais ça permettait aux administrateurs de disposer rapidement d’une machine à J-1 en cas de corruption, sans passer une sauvegarde réelle, ce qui était le besoin.

Installation de PowerCLI

Oui parce que bon. Ce n’est pas si simple ! Le VIPerl était casse pied à installer avec toutes les dépendances Perl, il n’y avait pas de raisons que le PowerCLI le soit plus. Merci VMware… ou Microsoft je ne sais pas ;-). Voici la marche à suivre

Récupérez l’installer sur le site de VMware (ex VMware-PowerCLI-5.1.0-793510.exe)
Exécutez l’installation en tant qu’administrateur de la machine.

Une fois installé, ouvrez le panneau de configuration pour désactiver la révocation des certificats :

Panneau de configuration/Options Internet/Onglet Avancé/Section Sécurité/Décocher Vérifier la révocation du certificat des éditeurs

A partir de là PowerCLI est « utilisable ». Pour autant, à l’époque sur les serveurs 2008 R2 (ça date !) il y avait un gros soucis de performance sur PowerCLI (VMware ou Microsoft, je n’ai jamais su), qui mettait plusieurs secondes (voire dizaines) avant de s’exécuter. La seule méthode permettant de gagner du temps était de précompiler le module PowerCLI (…) :

C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe install "VimService51.XmlSerializers, Version=5.1.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f"
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe install "VimService51.XmlSerializers, Version=5.1.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f"

Et avant de pouvoir exécuter des scripts PowerShell personnels, il faut modifier la politique de sécurité bloquant l’exécution dédits scripts. Personnellement je vous conseille de laisser en RemoteSigned mais à vous de voir.

Attention, comme il y a une partie x86 et une partie x64, il faudra lancer un prompt PowerShell en 32 bits et un en 64 bits avec les droits Administrateur (clic droit, lancer en tant qu’administrateur), puis exécuter la commande suivante dans les 2 terminaux :

Set-ExecutionPolicy RemoteSigned

Enfin, pour contourner 2 problèmes rencontrés IRL, on doit également lancer un prompt PowerCLI en 32 bits et un en 64 bits avec les droits Administrateur, puis exécuter les commandes suivantes (méthodes de contournement respectivement pour des problèmes de connexions dans les scripts et les problèmes de certificats) :

Set-PowerCLIConfiguration -ProxyPolicy NoProxy -Confirm:$False
Set-PowerCLIConfiguration -InvalidCertificateAction ignore -Confirm:$False

Commandes à exécuter manuellement, pour voir

Dans un premier temps (c’est à dire avant d’exécuter un script en priant pour que ça marche), le mieux est quand même de lancer les commandes à la main pour vérifier qu’on arrive à le faire au moins une fois manuellement.

Exemple de connexion au serveur vCenter (windows_vcenter) avec le login compte_privilegie présent dans le même domaine AD le vCenter.

Connect-VIServer -server windows_vcenter
Name Port User
---- ---- ----
windows_vcenter 443 DOMAINEAD\compte_privilegie

Normalement, après quelque s secondes la connexion devrait se faire. A partir de là, toutes les commandes suivantes seront authentifiées sur le vCenter.

Maintenant qu’on a réussi à se connecter, on démarrage d’une copie d’une VM vers un template. Ici je prends l’exemple du serveur vm_a_copier.

New-Template -Name vm_copie -VM vm_a_copier -Datastore DATASTORE_COPIE -Location VMWARE
Name
----
vm_copie

Dans la console, la copie devrait être en cours. Mission accomplie !

Je vous invite à aller sur le site de documentation VMware pour plus d’informations sur cette commande (lien mort, j’utilise Internet Archive).

Mise en place de la copie de la VM à proprement parler

Le script PowerShell

Ce sera donc un script PowerShell qui gèrera la copie de la VM (C:\scripts\vm_copie.ps1). Voici les étapes de ce script « exemple », à adapter à votre besoin.

Chargement du module PowerShell pour VMware

Add-PSSnapin -Name "VMware.VimAutomation.Core"

Connexion au vCenter en local (pas d’authentification nécessaire dans ce cas là)

$Server = Connect-VIServer -Server windows_vcenter -User vmwaresvc -Password mot_de_passe

Vérification préalable de l’existence ou non du template en question (on l’exécute tous les jours) et suppression le cas échant. Attention à ce que vous faites ici, en fonction de votre contexte !

$BackupTemplate = Get-Template -Name backup_srsmvm-supervision01 -Location VMWARE
If ($BackupTemplate){
Remove-Template -Template vm_copie -DeletePermanently -Confirm:$false
}
New-Template -Name vm_copie -VM vm_a_copier -Datastore DATASTORE_COPIE -Location VMWARE
Start-Sleep -s 10
Disconnect-VIServer -Server $Server -Confirm:$false

Et on se déconnecte proprement parce qu’on est sympa (et propres).

Permettre l’exécution automatique

On est contents, on a notre script. Pour autant ce n’est pas encore totalement terminé… Si vous connaissez un peu PowerShell (à voir si c’est toujours vrai sur les Windows Server récent, j’ai un doute…), vous savez qu’il était nécessaire de passer par un .bat ou un .vbs pour l’exécuter, ce qui n’était pas très pratique.

Avant de pouvoir créer une tâche planifiée Windows pour pouvoir automatiser notre copie, il va donc falloir créer un fichier vbs C:\scripts\vm_copie.vbs qui ne fera que lancer le fichier .ps1.

'Script VBScript de lancement des backups de VM
Set objShell = CreateObject("Wscript.Shell")
objShell.Run("powershell.exe C:\scripts\vm_copie.ps1")

Ce script vbs sera lancé par un compte de service (vmwaresvc par exemple) dans une tâche planifiée. Ce compte de service devra donc préalablement être autorisé à se connecter au vCenter et à réaliser des créations de templates.

Création d’un profil de sécurité et d’un compte pour la copie

Pour se faire, connectez vous au vCenter avec un compte administrateur VMware, puis créez un rôle disposant uniquement des autorisations nécessaires.

Menu Administration/Rôle/Ajouter…

Nom **« Compte de service copie_template »
**

Sélectionnez les privilèges suivants

Banque de données/Allouer espace
Machine virtuelle/Provisionnement/Créer un modèle à partir d’une machine virtuelle
Machine virtuelle/Inventaire/Créer à partir d’un modèle/d’une machine virtuelle existante
Machine virtuelle/Inventaire/Supprimer (attention danger !)

[Clic droit]Ajouter une autorisation

Ajouter…

Dans le menu déroulant Domaine, sélectionner VMWARE, puis ajouter l’utilisateur vmwaresvc. Dans Rôle assigné, sélectionner « Compte de service copie_template », et valider.

Et si vous avez bien suivi la logique, vous irez de vous même vous connecter au vCenter avec le compte vmwaresvc pour vérifier par vous même que l’opération fonctionne manuellement (car vous ne croyez que ce que vous voyez, et vous avez bien raison).

Restauration

Je ne pouvais pas terminer l’article sans au moins dire comment revenir en arrière une fois que vous avez besoin de repartir du template.

Comme il ne s’agit pas vraiment d’une VM mais d’un template, pour « restaurer » la machine virtuelle, il faut cliquer sur le template créé par le script et sélectionner Convertir en machine virtuelle ou Déployer machine virtuelle à partir de ce modèle.

Et voilà ! Je vous laisse le soin d’aller plus loin dans PowerShell / PowerCLI. Soyez créatifs ;-)

Paramètre caché XWiki pour résoudre l’erreur « fichier trop gros » lors de l’import d’un XAR

Sat, 12 Mar 2016 11:30:04 +0000

[Edit]

Ludovic DUBOST, CEO et fondateur de XWiki SAS m’a répondu (voir les commentaires). Le bug est connu mais a priori on doit utiliser les attachements de type Filesystem Attachment (pas le choix par défaut qui est le Database Attachment).

On trouve plus d’informations sur l’article suivant

www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments

The Filesystem attachment store saves your attachments in files in a directory tree. This means you will have one more thing to do when you back up your data but it also means you can save larger (over one gigabyte) files.

[/Edit]

Lorsque j’ai voulu importer une sauvegarde XAR un peu importante sous XWiki, je me suis retrouvé bloqué par la taille maximale des fichiers XAR que je pouvais importer. En effet par défaut, on est limité à 32 MB ce qui peut arriver rapidement avec des images/captures d’écran.

Et comme on ne peut pas faire un XAR avec uniquement une partie d’un wiki, il n’y a pas trop de solutions pour réduire la taille du XAR (vous pouviez quand même jouer sur la présence de l’historique des révisions ou pas, je ne sais pas si c’est toujours le cas).

[Edit]On peut faire des imports/exports plus précis avec des extensions comme LargeXARImport ou ImportExport, etc. [/Edit]

Pour autant, modifier cette limite purement logicielle (et arbitraire), il faut passer par des pages d’administration cachées.

La solution

Pour une raison que j’ignore, on ne peut ni accéder à ce paramètre dans les pages d’administration classique du wiki ni modifier une valeur dans les fichiers de configuration.

Il faut ouvrir une URL directement en mode « édition » sur les préférence du type :

http://@IPwiki:8080/xwiki-enterprise-web-7.2/bin/edit/XWiki/XWikiPreferences?editor=object

Si vous êtes au bon endroit, cela devrait ressembler à ça :

Cliquez sur la liste « XWikiPreferences 0 » **juste en dessous **de la ligne « XWiki.XWikiPreferences (1) ». Pas évident évident…

On y retrouve également des valeurs comme le serveur SMTP ou le serveur LDAP qu’on a paramétré côté xwiki.cfg, bizarrement ?

Modifiez le paramètres à la hausse pour correspondre à votre taille de fichier XAR, puis cliquez sur « Enregistrer et Fermer » pour valider.

Dans mon cas (PostgreSQL), ça marche, pas besoin de modifications supplémentaires, juste un redémarrage de tomcat.

Et la base de données ?

Pour autant, vous pourriez quand même avoir des ennuis si jamais votre base de données n’accepte pas les fichiers trop gros elle aussi, comme par exemple MySQL/MariaDB. Vous trouverez plus d’informations sur le sujet dans ce topic de la mailing list (lien mort, j’utilise Internet Archive) :

Pay also attention that your DB configuration could prevent you from uploading such a package. For exemple, with Mysql, you have to fix the value of max_allowed_packet in my.cnf file. If you want to upload a package of 35 MB for example, you need the value max_allowed_packet to be at least « 75M ».

Je ne suis pas certain de comprendre pourquoi il faut mettre max_allowed_packet à 75M pour un fichier de 35 MB. Visiblement il y a un coefficient x2 ?

Mais ça ne marche toujours pas

C’est fini ? Et bien non. Malheureusement, l’import de fichiers .XAR de XWiki est a priori une fonctionnalité très gourmande en mémoire et plante parfois juste après la fin de la barre de transfert :

Dans le fichier de log on pourra trouver une erreur de ce gout là :

Nov 12 17:02:23 @IPxwiki server: 2015-11-12 17:02:23,152 [http://@IPxwiki:8080/xwiki-enterprise-web-7.2/bin/upload/XWiki/XWikiPreferences] WARN c.x.x.w.UploadAction - Saving uploaded file failed
Nov 12 17:02:23 @IPxwiki server: Caused by: java.lang.OutOfMemoryError: Java heap space

Bon il semblerait que ce soit un problème connu depuis au moins 2008, si on en crois ce post (lien mort, j’utilise Internet Archive) et la réponse de Sergiu Dumitriu :

This is a major design flaw of the current attachment storage model. As stated in a previous mail, handling attachment consumes about 27 time the size of the attachment, so 90M * 27 ~= 2.5G. This needs to be fixed ASAP. In the meantime, you can either increase the heap size to more than 2.5G, or request an sql dump from the myxwiki farm admins.

27 FOIS

Effectivement, lorsque j’importe des XAR d’environ 60-70 Mo dans mon instance tomcat sizée à environ 2 Go, ça fonctionne, mais pas pour les fichiers de 80 Mo. La règle semble correspondre.

J’écrirais un autre article pour expliquer ce qu’on peut y faire dès que j’aurai un peu plus de matière.

Source

www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments