Sur Compute Engine, nous pouvons faire des instantanés, qui sont essentiellement des sauvegardes. Pourriez-vous essayer de comprendre comment nous pourrions créer un script pour créer des instantanés automatisés tous les jours et conserver 4 instantanés; donc, une fois que nous en aurons 4, supprimez le plus ancien. C’est la seule chose qui me préoccupe sur Google Cloud, c’est de ne pas avoir de sauvegardes planifiées du serveur, sinon j’aime beaucoup Compute Engine, c’est beaucoup plus facile à utiliser qu’Amazon et moins cher.
Documentation est assez clair sur la façon de le faire:
gcloud compute disks snapshot DISK
Notez que
Les instantanés sont toujours créés en fonction du dernier instantané réussi.
Et avant de supprimer vos instantanés, jetez un coup d’œil à ce diagramme:
Plus informations sur l'API.
METTRE À JOUR:
Le script a beaucoup changé depuis que j'ai donné cette réponse pour la première fois - veuillez consulter le dépôt Github pour le dernier code: https://github.com/jacksegal/google-compute-snapshot
RÉPONSE ORIGINALE:
J'ai eu le même problème, alors j'ai créé un script simple pour prendre un instantané quotidien et supprimer tous les instantanés sur 7 jours: https://github.com/Forward-Action/google-compute-snapshot
#!/usr/bin/env bash
export PATH=$PATH:/usr/local/bin/:/usr/bin
#
# CREATE DAILY SNAPSHOT
#
# get the device name for this vm
DEVICE_NAME="$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/disks/0/device-name" -H "Metadata-Flavor: Google")"
# get the device id for this vm
DEVICE_ID="$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/id" -H "Metadata-Flavor: Google")"
# get the zone that this vm is in
INSTANCE_ZONE="$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/zone" -H "Metadata-Flavor: Google")"
# strip out the zone from the full URI that google returns
INSTANCE_ZONE="${INSTANCE_ZONE##*/}"
# create a datetime stamp for filename
DATE_TIME="$(date "+%s")"
# create the snapshot
echo "$(gcloud compute disks snapshot ${DEVICE_NAME} --snapshot-names gcs-${DEVICE_NAME}-${DEVICE_ID}-${DATE_TIME} --zone ${INSTANCE_ZONE})"
#
# DELETE OLD SNAPSHOTS (OLDER THAN 7 DAYS)
#
# get a list of existing snapshots, that were created by this process (gcs-), for this vm disk (DEVICE_ID)
SNAPSHOT_LIST="$(gcloud compute snapshots list --regexp "(.*gcs-.*)|(.*-${DEVICE_ID}-.*)" --uri)"
# loop through the snapshots
echo "${SNAPSHOT_LIST}" | while read line ; do
# get the snapshot name from full URL that google returns
SNAPSHOT_NAME="${line##*/}"
# get the date that the snapshot was created
SNAPSHOT_DATETIME="$(gcloud compute snapshots describe ${SNAPSHOT_NAME} | grep "creationTimestamp" | cut -d " " -f 2 | tr -d \')"
# format the date
SNAPSHOT_DATETIME="$(date -d ${SNAPSHOT_DATETIME} +%Y%m%d)"
# get the expiry date for snapshot deletion (currently 7 days)
SNAPSHOT_EXPIRY="$(date -d "-7 days" +"%Y%m%d")"
# check if the snapshot is older than expiry date
if [ $SNAPSHOT_EXPIRY -ge $SNAPSHOT_DATETIME ];
then
# delete the snapshot
echo "$(gcloud compute snapshots delete ${SNAPSHOT_NAME} --quiet)"
fi
done
Ma solution est légèrement plus simple. Je veux prendre un instantané de tous les disques, pas seulement du disque principal.
En répertoriant tous les disques du projet, tous les serveurs sont gérés à partir d'un seul script, à condition qu'il soit exécuté dans un projet gcloud (et qu'il puisse également être modifié pour s'exécuter en dehors d'un serveur de projet.
Pour ranger les anciens clichés n'a pas besoin d'un traitement de date aussi complexe que celui-ci peut être traité à partir de la ligne de commande gcloud à l'aide d'un filtre.
https://gitlab.com/alan8/google-cloud-auto-snapshot
#!/bin/bash
# loop through all disks within this project and create a snapshot
gcloud compute disks list | tail -n +2 | while read DISK_NAME ZONE c3 c4; do
gcloud compute disks snapshot $DISK_NAME --snapshot-names auto-$DISK_NAME-$(date "+%s") --zone $ZONE
done
#
# snapshots are incremental and dont need to be deleted, deleting snapshots will merge snapshots, so deleting doesn't loose anything
# having too many snapshots is unwieldy so this script deletes them after 60 days
#
gcloud compute snapshots list --filter="creationTimestamp<$(date -d "-60 days" "+%Y-%m-%d") AND (auto.*)" --uri | while read SNAPSHOT_URI; do
gcloud compute snapshots delete --quiet $SNAPSHOT_URI
done
#
Notez également que pour les utilisateurs OSX, vous devez utiliser quelque chose comme:
$(date -j -v-60d "+%Y-%m-%d")
pour le filtre creationTimestamp
Le script suppose que $ HOSTNAME est identique à nom-disque (mon disque système principal prend le même nom que l’instance VM ou $ HOSTNAME - (à votre guise)), où qu’il soit indiqué $ HOSTNAME, il faut pour pointer sur le disque système de votre VM.
gcloud crée des instantanés diff incrémentaux. Le plus ancien contiendra le plus d'informations. Vous n'avez pas à vous soucier de la création d'un instantané complet. Si vous supprimez le plus ancien, le nouvel instantané le plus ancien devient le principal sur lequel seront basés les futurs incrémentiels. Tout cela est fait dans la logique de Google - il est donc automatique pour gcloud.
Nous avons ce script configuré pour s'exécuter sur un travail cron toutes les heures. Il crée un instantané incrémentiel (environ 1 à 2 Go) et supprime tout ce qui est plus ancien que les jours de rétention. Comme par magie, Google redimensionne l’instantané le plus ancien (qui était auparavant incrémental) pour devenir l’instantané de base. Vous pouvez le tester en supprimant l’instantané de base et en actualisant la liste des instantanés (console.cloud.google.com). La «magie» se produit en arrière-plan et vous devrez peut-être lui donner une minute pour se rebaser. Ensuite, vous remarquerez que l’instantané le plus ancien est la base et sa taille reflétera la partie utilisée du disque sur laquelle vous effectuez l’instantané.
#!/bin/bash
. ~/.bash_profile > /dev/null 2>&1 # source environment for cron jobs
retention=7 #days
zone=`gcloud info|grep zone:|awk -F\[ '{print $2}'|awk -F\] '{print $1}'`
date=`date +"%Y%m%d%H%M"`
expire=`date -d "-${retention} days" +"%Y%m%d%H%M"`
snapshots=`gcloud compute snapshots list --regexp "(${HOSTNAME}-.*)" --uri`
# Delete snapshots older than $expire
for line in "${snapshots[@]}"
do
snapshot=`echo ${line}|awk -F\/ '{print $10}'|awk -F\ '{print $1}'`
snapdate=`echo $snapshot|awk -F\- '{print $3}'`
if (( $snapdate <= $expire )); then
gcloud compute snapshots delete $snapshot --quiet
fi
done
# Create New Snapshot
gcloud compute disks snapshot $HOSTNAME --snapshot-name ${HOSTNAME}-${date} --zone $zone --description "$HOSTNAME Disk snapshot ${date}"
Ce qui suit est un script Ruby très grossier pour accomplir cette tâche. S'il vous plaît, considérez cela simplement comme un exemple d'inspiration.
Tous les commentaires pour l’améliorer sont les bienvenus ;-)
require 'date'
ARCHIVE = 30 # Days
DISKS = [] # The names of the disks to snapshot
FORMAT = '%y%m%d'
today = Date.today
date = today.strftime(FORMAT).to_i
limit = (today - ARCHIVE).strftime(FORMAT).to_i
# Backup
`gcloud compute disks snapshot #{DISKS.join(' ')} --snapshot-names #{DISKS.join("-#{date},")}-#{date}`
# Rotate
snapshots = []
`gcloud compute snapshots list`.split("\n").each do |row|
name = date
row.split("\s").each do |cell|
name = cell
break
end
next if name == 'NAME'
snapshots << name if name[-6, 6].to_i < limit
end
`yes | gcloud compute snapshots delete #{snapshots.join(' ')}` if snapshots.length > 0
Il existe maintenant une fonctionnalité appelée "Planification d'instantané" disponible dans GCP.
Il semble toujours être en version bêta, et il n’ya pas encore beaucoup de documentation sur cette fonctionnalité . Mais c’est un processus simple pour l’activer . Vous devez d’abord créer un programme de capture instantanée et l’affecter aux disques persistants après. vous l'avez mis en place.
Voir aussi la référence de ligne de commande pour créer une planification avec la commande correspondante gcloud:
gcloud beta compute resource-policies create-snapshot-schedule
Pour affecter la planification à un disque persistant, vous pouvez utiliser la commande
gcloud beta compute disks add-resource-policies
https://cloud.google.com/sdk/gcloud/reference/beta/compute/disks/add-resource-policies
Mise à jour 2019-02-15: Depuis hier, il existe une annonce de blog à propos de la fonctionnalité d'instantanés planifiés ainsi qu'une page dans la documentation de Compute Engine pour instantanés planifiés .
De plus, au moment de la rédaction de ce document, les instances Windows prennent en charge le service VSS (Volume Shadow Copy Service), contrairement aux instances Linux.
Par conséquent, vous pouvez capturer en toute sécurité les lecteurs Windows lorsque l'instance est en cours d'exécution à l'aide du commutateur --guest-flush, mais pas pour les lecteurs Linux.
Avant de prendre des clichés instantanés de disques Linux, vous aurez besoin d’un autre mécanisme pour le préparer au cliché instantané, à savoir figer le lecteur, détacher le lecteur ou mettre l’instance hors tension.
Si rien d'autre, je sais que [--set-scheduling]
est un indicateur de situation gcloud et qu'il existe un wait [process]
qui empêchera la commande en cours de s'exécuter jusqu'à la fin du processus. Combinez cela avec l'opérateur &&
(exécute les commandes de même instruction une fois la précédente terminée), ce qui ne devrait pas être trop difficile. Il suffit de l’exécuter au démarrage (lorsque vous créez une instance, il dispose d’une option de commande de démarrage) et de le faire compter ou de faire en sorte que l’une des fonctions de maintenance habituelle déclenche les commandes. Mais honnêtement, pourquoi mélanger la syntaxe si vous n’avez pas à le faire?
Cela pourrait fonctionner (ne pas copier/coller)
gcloud config set compute/zone wait [datetime-function] && \
gcloud compute disks snapshot snap1 snap2 snap3 \
--snapshot-names ubuntu12 ubuntu14 debian8 \
--description=\
'--format="multi(\
info:format=list always-display-title compact,\
data:format=list always-display-title compact\
)"'
En théorie, gcloud définira le calcul/zone, mais devra attendre le temps spécifié. En raison de la double esperluette (&&), la commande suivante ne sera exécutée qu'une fois la première commande terminée. Je suis peut-être allé trop loin dans la description, mais je l’ai fait pour montrer sa simplicité. Je sais que cela ne fonctionnera pas tel quel, mais je sais aussi que je ne suis pas si loin. Wow, après avoir examiné tout le code, on pourrait croire que nous essayons de résoudre la séquence d'immortalité. Je ne pense pas que travailler dans un fichier bash soit la meilleure solution. gcloud a créé une ligne de commande pour les personnes qui ne connaissent pas la ligne de commande. Nous avons appris (ou appris ... ou n'avons pas encore appris) à écrire le code de manière appropriée par rapport à l'environnement. Je dis que nous appliquons cela ici et utilisons le SDK CLOUD à notre avantage.