web-dev-qa-db-fra.com

Stratégies de sauvegarde pour le compartiment AWS S3

Je recherche des conseils ou des meilleures pratiques pour sauvegarder le compartiment S3.
Le but de la sauvegarde des données de S3 est d'empêcher la perte de données pour les raisons suivantes:

  1. Problème S3
  2. problème où je supprime accidentellement ces données de S3

Après quelques recherches, je vois les options suivantes:

  1. Utilisez le contrôle de version http://docs.aws.Amazon.com/AmazonS3/latest/dev/Versioning.html
  2. Copiez d'un compartiment S3 vers un autre à l'aide d'AWS SDK
  3. Sauvegarde sur Amazon Glacier http://aws.Amazon.com/en/glacier/
  4. Sauvegarde sur le serveur de production, lui-même sauvegardé

Quelle option dois-je choisir et dans quelle mesure serait-il sûr de stocker des données uniquement sur S3? Vous voulez entendre vos opinions.
Quelques liens utiles:

amazon-web-servicesamazon-s3backupamazon-glacier
55
Sergey Alekseev

Publié à l'origine sur mon blog: http://eladnava.com/backing-up-your-Amazon-s3-buckets-to-ec2/

Synchronisez régulièrement votre compartiment S3 avec un serveur EC2

Cela peut être facilement réalisé en utilisant plusieurs utilitaires de ligne de commande qui permettent de synchroniser un compartiment S3 distant avec le système de fichiers local.

s3cmd
En premier, s3cmd avait l'air extrêmement prometteur. Cependant, après l'avoir essayé sur mon énorme seau S3 - il n'a pas réussi à évoluer, avec une erreur Segmentation fault. Cela a bien fonctionné sur les petits seaux, cependant. Comme cela ne fonctionnait pas pour les énormes seaux, je me suis mis à chercher une alternative.

s4cmd
L'alternative plus récente et multithread à s3cmd. Cela semblait encore plus prometteur, cependant, j'ai remarqué qu'il continuait de télécharger à nouveau des fichiers qui étaient déjà présents sur le système de fichiers local. Ce n'est pas le genre de comportement que j'attendais de la commande de synchronisation. Il devrait vérifier si le fichier distant existe déjà localement (la vérification du hachage/de la taille de fichier serait soignée) et l'ignorer lors de la prochaine synchronisation sur le même répertoire cible. J'ai ouvert un problème ( bloomreach/s4cmd/# 46 ) pour signaler ce comportement étrange. En attendant, je me suis mis à chercher une autre alternative.

awscli
Et puis j'ai trouvé awscli. Il s'agit de l'interface de ligne de commande officielle d'Amazon pour interagir avec leurs différents services cloud, S3 inclus.

AWSCLI

Il fournit une commande de synchronisation utile qui télécharge rapidement et facilement les fichiers de compartiment distant sur votre système de fichiers local .

$ aws s3 sync s3: // votre-nom-seau/home/ubuntu/s3/votre-nom-seau /

Avantages:

  • Évolutif - prend en charge d'énormes godets S3
  • Multi-thread - synchronise les fichiers plus rapidement en utilisant plusieurs threads
  • Smart - synchronise uniquement les fichiers nouveaux ou mis à jour
  • Rapide - grâce à sa nature multi-thread et à son algorithme de synchronisation intelligent

Suppression accidentelle

Idéalement, la commande sync ne supprimera pas les fichiers du dossier de destination (système de fichiers local) s'ils sont absents de la source (compartiment S3), et vice-versa. C'est parfait pour sauvegarder S3 - dans le cas où des fichiers sont supprimés du bucket, la resynchronisation ne les supprimera pas localement. Et si vous supprimez un fichier local, il ne sera pas non plus supprimé du compartiment source.

Configurer awscli sur Ubuntu 14.04 LTS

Commençons par installer awscli. Il y a plusieurs façons pour ce faire, cependant, j'ai trouvé plus facile de l'installer via apt-get.

$ Sudo apt-get install awscli

Configuration

Ensuite, nous devons configurer awscli avec notre ID de clé d'accès et notre clé secrète, que vous devez obtenir auprès de IAM , en créant un utilisateur et attacher la stratégie AmazonS3ReadOnlyAccess . Cela vous empêchera également, vous ou quiconque ayant accès à ces informations d'identification, de supprimer vos fichiers S3. Assurez-vous d'entrer votre région S3, telle que us-east-1.

$ aws configure

aws configure

Préparation

Préparons le répertoire de sauvegarde S3 local, de préférence dans /home/ubuntu/s3/{BUCKET_NAME}. Assurez-vous de remplacer {BUCKET_NAME} avec le nom réel de votre compartiment.

$ mkdir -p/home/ubuntu/s3/{BUCKET_NAME}

Synchronisation initiale

Allons de l'avant et synchronisons le compartiment pour la première fois avec la commande suivante:

$ aws s3 sync s3: // {BUCKET_NAME}/home/ubuntu/s3/{BUCKET_NAME} /

En supposant que le compartiment existe, que les informations d'identification et la région AWS sont correctes et que le dossier de destination est valide, awscli commencera à télécharger le compartiment entier vers le système de fichiers local.

Selon la taille du compartiment et votre connexion Internet, cela peut prendre de quelques secondes à quelques heures. Une fois cela fait, nous irons de l'avant et configurerons une tâche cron automatique pour garder la copie locale du compartiment à jour.

Configuration d'un travail Cron

Allez-y et créez un sync.sh fichier dans /home/ubuntu/s3:

$ nano /home/ubuntu/s3/sync.sh

Copiez et collez le code suivant dans sync.sh:

#!/bin/sh 
 
 # Faire écho à la date et à l'heure actuelles 
 
 echo '--------------- -------------- '
 date 
 écho' ---------------------- ------- '
 echo' '
 
 # Initialisation du script d'écho 
 echo' Synchronisation du bucket S3 distant ... '
 
 # Exécutez réellement la commande de synchronisation (remplacez {BUCKET_NAME} par votre nom de compartiment S3) 
/Usr/bin/aws s3 sync s3: // {BUCKET_NAME}/home/ubuntu/s3/{ BUCKET_NAME}/
 
 # Achèvement du script d'écho 
 Echo 'Sync complete'

Assurez-vous de remplacer {BUCKET_NAME} par votre nom de compartiment S3, deux fois dans le script.

Astuce Pro: Vous devez utiliser /usr/bin/aws pour créer un lien vers le binaire aws, car crontab exécute des commandes dans un environnement Shell limité et ne pourra pas trouver l'exécutable par lui-même.

Ensuite, assurez-vous de chmod le script afin qu'il puisse être exécuté par crontab.

$ Sudo chmod + x /home/ubuntu/s3/sync.sh

Essayons d'exécuter le script pour nous assurer qu'il fonctionne réellement:

$ /home/ubuntu/s3/sync.sh

La sortie doit être similaire à ceci:

sync.sh output

Ensuite, modifions le crontab de l'utilisateur actuel en exécutant la commande suivante:

$ crontab -e

Si c'est la première fois que vous exécutez crontab -e, vous devrez sélectionner un éditeur préféré. Je recommanderais de sélectionner nano car c'est le plus simple pour les débutants.

Fréquence de synchronisation

Nous devons indiquer à crontab à quelle fréquence exécuter notre script et où le script réside sur le système de fichiers local en écrivant une commande. Le format de cette commande est le suivant:

commande m h dom mon dow

La commande suivante configure crontab pour exécuter le sync.sh script toutes les heures (spécifié via les paramètres minute: 0 et hour: *) et pour qu'il dirige la sortie du script vers un sync.log fichier dans notre s3 répertoire:

0 * * * * /home/ubuntu/s3/sync.sh> /home/ubuntu/s3/sync.log

Vous devez ajouter cette ligne au bas du fichier crontab que vous modifiez. Ensuite, allez-y et enregistrez le fichier sur le disque en appuyant sur Ctrl + W puis sur Entrée . Vous pouvez ensuite quitter nano en appuyant sur Ctrl + X . crontab exécutera désormais la tâche de synchronisation toutes les heures.

Astuce de pro: Vous pouvez vérifier que le travail cron horaire est exécuté avec succès en inspectant /home/ubuntu/s3/sync.log, en vérifiant son contenu pour la date et l'heure d'exécution, et en inspectant les journaux pour voir quels nouveaux fichiers ont été synchronisés.

Tout est prêt! Votre compartiment S3 sera désormais synchronisé automatiquement avec votre serveur EC2 toutes les heures, et vous devriez être prêt à partir. Notez qu'au fil du temps, à mesure que votre compartiment S3 s'agrandit, vous devrez peut-être augmenter la taille du volume EBS de votre serveur EC2 pour accueillir de nouveaux fichiers. Vous pouvez toujours augmenter la taille de votre volume EBS en suivant ce guide .

39
Elad Nava

Compte tenu du lien connexe, qui explique que le S3 a une durabilité de 99,999999999%, je rejetterais votre préoccupation n ° 1. Sérieusement.

Maintenant, si # 2 est un cas d'utilisation valide et une réelle préoccupation pour vous, je resterais certainement avec les options # 1 ou # 3. Lequel d'entre eux? Cela dépend vraiment de certaines questions:

  • Avez-vous besoin d'autres fonctionnalités de gestion des versions ou est-ce uniquement pour éviter les remplacements/suppressions accidentelles?
  • Le coût supplémentaire imposé par le versioning est-il abordable?
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. C'est bon pour toi?

À moins que votre utilisation du stockage ne soit vraiment énorme, je resterais fidèle à la version du bucket. De cette façon, vous n'aurez pas besoin de code/flux de travail supplémentaire pour sauvegarder les données sur Glacier, sur d'autres compartiments ou même sur n'importe quel autre serveur (ce qui est vraiment un mauvais choix à mon humble avis, veuillez l'oublier).

23
Viccari

Vous penseriez qu'il y aurait maintenant un moyen plus simple de simplement conserver une sorte de sauvegardes incrémentielles sur une région diff.

Toutes les suggestions ci-dessus ne sont pas des solutions vraiment simples ou élégantes. Je ne considère pas vraiment glacier comme une option car je pense que c'est plus une solution d'archivage qu'une solution de sauvegarde. Quand je pense à la sauvegarde, je pense que la récupération après sinistre d'un développeur junior supprime récursivement un compartiment ou peut-être un exploit ou un bogue dans votre application qui supprime des éléments de s3.

Pour moi, la meilleure solution serait un script qui sauvegarde simplement un seau dans une autre région, un par jour et une par semaine afin que si quelque chose de terrible se produit, vous pouvez simplement changer de région. Je n'ai pas de configuration comme celle-ci, j'ai cherché à ne pas y arriver car cela prendrait un peu d'effort pour le faire, c'est pourquoi je souhaite qu'il y ait une solution stock à utiliser.

8
David

Vous pouvez sauvegarder vos données S3 en utilisant les méthodes suivantes

  1. Planifiez le processus de sauvegarde à l'aide de la ligne de données AWS, cela peut être fait de 2 manières mentionnées ci-dessous:

    une. Utilisation de copyActivité de la ligne de données à l'aide de laquelle vous pouvez copier d'un compartiment s3 vers un autre compartiment s3.

    b. Utilisation de ShellActivity de la ligne de données et des commandes "S3distcp" pour effectuer la copie récursive des dossiers récursifs s3 d'un compartiment à un autre (en parallèle).

  2. Utilisez la gestion des versions à l'intérieur du compartiment S3 pour gérer différentes versions des données

  3. Utilisez glacier pour sauvegarder vos données (utilisez-le lorsque vous n'avez pas besoin de restaurer rapidement la sauvegarde dans les compartiments d'origine (cela prend un certain temps pour récupérer les données de glacier car les données sont stockées au format compressé) ou lorsque vous souhaitez enregistrer certains coûts en évitant d'utiliser un autre compartiment s3 pour la sauvegarde), cette option peut facilement être définie à l'aide de la règle de cycle de vie sur le compartiment s3 pour lequel vous souhaitez effectuer la sauvegarde.

L'option 1 peut vous donner plus de sécurité, disons au cas où vous supprimeriez accidentellement votre compartiment s3 d'origine et un autre avantage est que vous pouvez stocker votre sauvegarde dans des dossiers de date dans un autre compartiment s3, de cette façon, vous savez quelles données vous aviez à une date particulière et pouvez restaurer une sauvegarde de date spécifique. Tout dépend de votre cas d'utilisation.

8
Varun

Que diriez-vous d'utiliser la fonctionnalité Cross Region Replication facilement disponible sur les compartiments S3 lui-même? Voici quelques articles utiles sur la fonctionnalité

8
Adrian Teh

Bien que cette question ait été publiée il y a quelque temps, j'ai pensé qu'il était important de mentionner la protection MFA delete avec les autres solutions. L'OP essaie de résoudre la suppression accidentelle des données. L'authentification multifacteur (MFA) se manifeste dans deux scénarios différents ici -

  1. Suppression définitive des versions d'objet - Activez la suppression MFA sur la gestion des versions du compartiment.

  2. Suppression accidentelle du compartiment lui-même - Configurez une stratégie de compartiment refusant la suppression sans authentification MFA.

À coupler avec réplication inter-régions et versioning pour réduire le risque de perte de données et améliorer les scénarios de récupération.

Voici un article de blog sur ce sujet avec plus de détails.

1
user1590603