Stratégies de sauvegarde pour le seau AWS S3

Question

Je cherche des conseils ou les meilleures pratiques pour sauvegarder S3 bucket.
L'objectif de la sauvegarde des données de S3 est d'éviter la perte de données pour les raisons suivantes :

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

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

1. Utiliser les versions http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
2. Copie d'un seau S3 à un autre à l'aide d'AWS SDK
3. Sauvegarde vers Amazon Glacier http://aws.amazon.com/en/glacier/
4. Sauvegarde sur le serveur de production, qui est lui-même sauvegardé

Quelle option dois-je choisir et quelle serait la sécurité de stocker les données uniquement sur S3 ? J'aimerais connaître votre avis.
Quelques liens utiles :

• Documentation sur la protection des données
• FAQ sur la protection des données

Answer 1

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

Synchronisez périodiquement votre godet S3 sur un serveur EC2

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

s3cmd
Au début, s3cmd semblait extrêmement prometteur. Cependant, après l'avoir essayé sur mon énorme seau S3, il n'a pas réussi à se mettre à l'échelle, avec un message d'erreur Segmentation fault . Il a cependant bien fonctionné sur les petits seaux. Comme il ne fonctionnait pas pour les grands seaux, je me suis mis à la recherche d'une alternative.

s4cmd
L'alternative plus récente et multi-filière à s3cmd . semblait encore plus prometteur, mais j'ai remarqué qu'il continuait à retélécharger 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 sync. Elle devrait vérifier si le fichier distant existe déjà localement (une vérification du hachage/de la taille des fichiers serait utile) et l'ignorer lors de la prochaine synchronisation sur le même répertoire cible. J'ai ouvert une question ( bloomreach/s4cmd/#46 ) pour signaler ce comportement étrange. En attendant, j'ai entrepris de trouver une autre solution.

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

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

$ aws s3 sync s3://your-bucket-name /home/ubuntu/s3/your-bucket-name/

Avantages :

• Évolutif - prend en charge les énormes seaux S3
• Multithreaded - synchronisation des fichiers plus rapide grâce à l'utilisation de plusieurs threads.
• Smart - ne synchronise que les fichiers nouveaux ou mis à jour
• Rapide - grâce à sa nature multithread et à son algorithme de synchronisation intelligent.

Suppression accidentelle

De façon pratique, le sync ne supprimera pas les fichiers du dossier de destination (système de fichiers local) s'ils sont absents de la source (seau S3), et vice-versa. C'est parfait pour la sauvegarde de S3 - si des fichiers sont supprimés du seau, la resynchronisation ne les supprimera pas localement. Et si vous supprimez un fichier local, il ne sera pas non plus supprimé du seau source.

Configuration d'awscli sur Ubuntu 14.04 LTS

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

$ sudo apt-get install awscli

Configuration

Ensuite, nous devons configurer awscli à l'aide de notre ID de clé d'accès et de notre clé secrète, que vous devez obtenir auprès de la Commission européenne. IAM en créant un utilisateur et en attachant le AmazonS3ReadOnlyAccess politique. Cela vous empêchera également, vous ou toute personne 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

Préparation

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

$ mkdir -p /home/ubuntu/s3/{BUCKET\_NAME}

Synchronisation initiale

Allons-y et synchronisons le seau pour la première fois avec la commande suivante :

$ aws s3 sync s3://{BUCKET\_NAME} /home/ubuntu/s3/{BUCKET\_NAME}/

En supposant que le seau existe, que les informations d'identification AWS et la région sont correctes et que le dossier de destination est valide, awscli va commencer à télécharger l'ensemble du panier sur le système de fichiers local.

En fonction de la taille du seau et de votre connexion Internet, cela peut prendre de quelques secondes à plusieurs heures. Une fois l'opération terminée, nous allons mettre en place une tâche cron automatique pour maintenir à jour la copie locale du seau.

Configuration d'une tâche Cron

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

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

Copiez et collez le code suivant dans sync.sh :

#!/bin/sh

# Echo the current date and time

echo '-----------------------------'
date
echo '-----------------------------'
echo ''

# Echo script initialization
echo 'Syncing remote S3 bucket...'

# Actually run the sync command (replace {BUCKET\_NAME} with your S3 bucket name)
/usr/bin/aws s3 sync s3://{BUCKET\_NAME} /home/ubuntu/s3/{BUCKET\_NAME}/

# Echo script completion
echo 'Sync complete'

Veillez à remplacer {BUCKET_NAME} avec votre nom de seau S3, deux fois dans le script.

Un conseil de pro : Vous devez utiliser /usr/bin/aws pour établir un lien avec le aws binaire, comme crontab exécute les commandes dans un environnement shell limité et ne sera pas en mesure de trouver l'exécutable par lui-même.

Ensuite, assurez-vous de chmod le script pour qu'il puisse être exécuté par les personnes suivantes 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

Le résultat devrait être similaire à celui-ci :

Ensuite, nous allons modifier le fichier de l'utilisateur actuel. crontab 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 vous recommande de choisir nano car c'est le plus facile à utiliser pour les débutants.

Fréquence de synchronisation

Nous devons dire 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 :

m h  dom mon dow   command

La commande suivante configure crontab pour exécuter le sync.sh script toutes les heures (spécifiées par les paramètres minute:0 et heure:*) et de faire en sorte que la sortie du script soit envoyée à un fichier de type sync.log dans notre s3 répertoire :

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

Vous devez ajouter cette ligne au bas de la page d'accueil. crontab que vous éditez. Ensuite, allez-y et enregistrez le fichier sur le disque en appuyant sur Ctrl + W et ensuite Entrez . Vous pouvez alors quitter nano en appuyant sur Ctrl + X . crontab va maintenant exécuter la tâche de synchronisation toutes les heures.

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

Tout est prêt ! Votre seau S3 sera maintenant synchronisé avec votre serveur EC2 toutes les heures automatiquement, et vous devriez être prêt à partir. Notez qu'au fil du temps, lorsque votre seau S3 devient plus grand, vous devrez peut-être augmenter la taille du volume EBS de votre serveur EC2 pour accueillir les nouveaux fichiers. Vous pouvez toujours augmenter la taille de votre volume EBS en suivant les instructions suivantes ce guide .

Answer 2

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

Maintenant, si le point 2 est un cas d'utilisation valide et une réelle préoccupation pour vous, je m'en tiendrais définitivement aux options 1 ou 3. Laquelle des deux ? Cela dépend vraiment de certaines questions :

• Avez-vous besoin d'autres fonctions de gestion des versions ou s'agit-il uniquement d'éviter les écrasements/suppressions accidentels ?
• 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. Est-ce que cela vous convient ?

À moins que votre utilisation du stockage ne soit vraiment énorme, je m'en tiendrais à la gestion des versions des seaux. De cette façon, vous n'aurez pas besoin de code/flux de travail supplémentaire pour sauvegarder des données vers Glacier, vers d'autres bucket, ou même vers un autre serveur (ce qui est vraiment un mauvais choix IMHO, veuillez l'oublier).

Answer 3

Que diriez-vous d'utiliser l'outil facilement disponible Réplication transrégionale sur les bouquets S3 eux-mêmes ? Voici quelques articles utiles sur cette fonctionnalité

• https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/
• http://docs.aws.amazon.com/AmazonS3/latest/UG/cross-region-replication.html

Answer 4

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

1. Planifier le processus de sauvegarde en utilisant AWS datapipeline ,cela peut être fait de 2 façons mentionnées ci-dessous :

   a. En utilisant copyActivity de datapipeline, vous pouvez copier d'un s3 bucket à un autre s3 bucket.

   b. Utiliser ShellActivity de datapipeline et les commandes "S3distcp" pour faire la copie récursive des dossiers s3 récursifs d'un seau à l'autre (en parallèle).

2. Utilisez le versioning dans le seau S3 pour maintenir 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 seaux d'origine (il faut un certain temps pour récupérer les données de Glacier car les données sont stockées dans un format compressé) ou lorsque vous voulez économiser de l'argent en évitant d'utiliser un autre seau s3 pour la sauvegarde), cette option peut facilement être définie en utilisant la règle de cycle de vie sur le seau s3 pour lequel vous voulez faire une sauvegarde.

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

Answer 5

On pourrait penser qu'il y aurait maintenant un moyen plus facile d'effectuer des sauvegardes incrémentielles sur une région différente.

Toutes les suggestions ci-dessus ne sont pas vraiment des solutions 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 à la reprise après sinistre d'un développeur junior qui supprime récursivement un bucket ou peut-être un exploit ou un bug dans votre application qui supprime des choses de s3.

Pour moi, la meilleure solution serait un script qui sauvegarde juste un seau dans une autre région, un quotidien et un hebdomadaire de sorte que si quelque chose de terrible se produit, vous pouvez simplement changer de région. Je n'ai pas une configuration comme ça, j'ai regardé dans juste n'ont pas eu le temps de le faire parce qu'il faudrait un peu d'effort pour le faire qui est pourquoi je souhaite qu'il y avait une solution de stock à utiliser.