Stratégies de sauvegarde pour le compartiment AWS S3


92

Je recherche des conseils ou des bonnes pratiques pour sauvegarder le compartiment S3.
Le but de la sauvegarde des données depuis S3 est d'éviter 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 la gestion des versions http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
  2. Copier d'un compartiment S3 vers un autre à l'aide du kit 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:


Réponses:


63

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
Au début, s3cmdsemblait extrêmement prometteur. Cependant, après l'avoir essayé sur mon énorme compartiment S3 - il n'a pas réussi à évoluer, erreur avec un Segmentation fault. Cela fonctionnait bien sur de petits seaux, cependant. Comme cela ne fonctionnait pas pour d'énormes seaux, je me suis mis à trouver une alternative.

s4cmd
La nouvelle alternative multithread à s3cmd. Cela avait l'air encore plus prometteur, cependant, j'ai remarqué qu'il continuait à té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. Il devrait vérifier si le fichier distant existe déjà localement (la vérification du hachage / taille du fichier serait bien) et l'ignorer lors de la prochaine synchronisation sur le même répertoire cible. J'ai ouvert un numéro ( bloomreach / s4cmd / # 46 ) pour signaler ce comportement étrange. En attendant, je me suis mis à trouver 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: // nom-de-votre-bucket / home / ubuntu / s3 / nom-de-votre-bucket /

Avantages:

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

Suppression accidentelle

Idéalement, le sync commande 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 - au cas où des fichiers seraient supprimés du compartiment, la resynchronisation ne les supprimera pas localement. Et si vous supprimez un fichier local, il ne sera pas non plus supprimé du bucket source.

Configurer awscli sur Ubuntu 14.04 LTS

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

$ sudo apt-get install awscli

Configuration

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

$ aws configurer

aws configurer

Préparation

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

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

Synchronisation initiale

Allons-y et synchronisons le bucket 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, les informations d'identification AWS et la région sont correctes et le dossier de destination est valide, awsclicommencera à télécharger le compartiment entier sur le système de fichiers local.

En fonction de la taille du compartiment et de votre connexion Internet, cela peut prendre de quelques secondes à quelques heures. Lorsque cela est fait, nous allons mettre en place une tâche cron automatique pour maintenir la copie locale du bucket à jour.

Configurer un travail Cron

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

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

Copiez et collez le code suivant dans sync.sh:

#! / bin / sh

# Écho la date et l'heure actuelles

écho '-----------------------------'
Date
écho '-----------------------------'
écho ''

# Initialisation du script d'écho
echo 'Synchronisation du compartiment S3 distant ...'

# Exécutez en fait la commande de synchronisation (remplacez {BUCKET_NAME} par le nom de votre compartiment S3)
/ usr / bin / aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# Achèvement du script d'écho
echo 'Synchronisation terminée'

Assurez-vous de remplacer {BUCKET_NAME} par le nom de votre compartiment S3, deux fois tout au long du script.

/usr/bin/awsConseil de pro: vous devriez utiliser pour créer un lien vers le awsbinaire, car il crontabexécute des commandes dans un environnement shell limité et ne pourra pas trouver l'exécutable par lui-même.

Ensuite, assurez-vous que chmodle script peut ê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:

sortie sync.sh

Ensuite, éditons l'utilisateur actuel crontaben exécutant la commande suivante:

$ crontab -e

Si c'est votre première exécution crontab -e, vous devrez sélectionner un éditeur préféré. Je recommanderais de sélectionner nanocar c'est le plus facile à utiliser pour les débutants.

Fréquence de synchronisation

Nous devons dire à crontabquelle 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 mh dom mon dow

La commande suivante se configure crontabpour exécuter le sync.shscript toutes les heures (spécifié via les paramètres minute: 0 et hour: *) et pour qu'il redirige la sortie du script vers un sync.logfichier dans notre s3répertoire:

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

Vous devez ajouter cette ligne au bas du crontabfichier que vous modifiez. Ensuite, continuez et enregistrez le fichier sur le disque en appuyant sur Ctrl + W puis sur Entrée . Vous pouvez ensuite quitter nanoen appuyant sur Ctrl + X . crontabva maintenant exécuter la tâche de synchronisation toutes les heures.

Conseil 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 automatiquement synchronisé avec votre serveur EC2 toutes les heures, et vous devriez être prêt à partir. Notez qu'avec le 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 .


J'ai laissé une question sur votre blog, mais je me demande s'il existe un moyen de synchroniser les métadonnées aussi?
Devology Ltd

@Devology Ltd, Malheureusement, je n'ai pas eu l'occasion de travailler avec les métadonnées d'objets S3. À partir d'une recherche rapide sur Google, il ne semble pas que les awsclisupports synchronisent cela automatiquement dans la aws s3 synccommande. Il semble que vous deviez peut-être implémenter cela manuellement.
Elad Nava

Merci @Ekad Nava - Je vous remercie d'avoir confirmé ce que je pensais être le cas.
Devology Ltd

1
C'est fantastique @EladNava merci pour le partage, toujours d'actualité en 2020!
user1130176

cette réponse ne convient pas, lorsque vous avez des millions de fichiers. Cela devient très coûteux, lent et parfois impossible - à cause des limites du système de fichiers.
Psychozoic

30

Compte tenu du lien associé, qui explique que 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 m'en tiendrai certainement aux options # 1 ou # 3. Lequel d'entre eux? Cela dépend vraiment de quelques questions:

  • Avez-vous besoin d'autres fonctionnalités de contrôle de version ou est-ce uniquement pour éviter les écrasements / suppressions accidentelles?
  • Le coût supplémentaire imposé par la gestion des versions 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 de stockage ne soit vraiment énorme, je m'en tiendrais à la gestion des versions de seau. 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 seaux ou même sur tout autre serveur (ce qui est vraiment un mauvais choix à mon humble avis, oubliez-le).


4
@SergeyAlekseev Si Glacier est quelque chose qui fonctionne pour vous, il est très rapide de mettre en place une règle de cycle de vie sur un bucket qui archive automatiquement vos fichiers dans glacier. Ils apparaîtront toujours dans un seau (dans l'interface utilisateur Web), mais la classe de stockage passera de standard à glacier. Je déplace les fichiers traités de mon bucket principal vers un bucket "done", et le bucket done contient la règle du cycle de vie qui archive tout ce qui date de plus d'un jour. Ce sont des fichiers de données que je ne toucherai probablement plus jamais, mais que je dois conserver pour le client.
Dan

28
Je ne pense pas que 99,999999999% soit une bonne raison suffisante pour être une pile aws complète sur le stockage / sauvegarde. Je ne parle pas des 0,000000000001% restants, mais plus si quelque chose de très inattendu se produit, il est gênant d'avoir toute votre entreprise quelque part. Par inattendu, il pourrait s'agir des États-Unis qui entrent en guerre contre un pays spécifique, Amazon étant complètement piraté (cf. Sony), etc. etc.
Augustin Riedinger

11
Je reviendrai sur @AugustinRiedinger sur celui-ci: "Problème S3" peut être par définition quelque chose que vous ne connaissez pas (par exemple des problèmes gouvernementaux) qui pourrait invalider les hypothèses sur lesquelles les numéros SLA S3 comme 99.99 ... sont basés. Lorsque vous faites quelque chose à long terme, y compris la sauvegarde de vos données, la diversification est une bonne pratique, sinon devrait être une condition préalable
lajarre

2
Je suis tout à fait d'accord que vos points sont valides. Mais sur la base des options offertes par l'OP (à peu près toutes, y compris les alternatives AWS au problème), je ne pense pas que le "problème S3" serait aussi large que vous le développez. C'est bien de voir quelques pensées plus larges, cependant.
Viccari

4
Ancienne réponse, mais j'ai l'impression de devoir mentionner les événements (-ish) récents. "Le jour où Amazon a cassé le Web", une technologie a accidentellement supprimé une grande partie de ses serveurs S3. Même pendant ces 24 heures, le problème était l'accessibilité. Pas de perte de données. Il n'y a eu absolument aucune perte de données, même compte tenu de la grande quantité de serveurs supprimés, et ils ont quand même réussi à respecter leur SLA
Oberst

14

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 effectué de deux manières mentionnées ci-dessous:

    une. Utilisation de copyActivity de datapipeline à l'aide de laquelle vous pouvez copier d'un compartiment s3 vers un autre compartiment s3.

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

  2. Utiliser la gestion des versions dans le compartiment S3 pour conserver 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 au format compressé) ou lorsque vous souhaitez enregistrer un certain coût 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 à partir duquel vous souhaitez effectuer une sauvegarde.

L'option 1 peut vous donner plus de sécurité, par exemple 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 par 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.


@David: Comme David l'a suggéré dans sa solution ci-dessous, qu'il pourrait y avoir un script qui sauvegarde le bucket s3 quotidiennement ou hebdomadairement, cela peut être facilement atteint par mon premier point (AWS datapipeline- qui vous donne la possibilité de planifier le processus de sauvegarde -daily , hebdomadaire etc.). Je recommanderais de faire une recherche sur la ligne de données aws.
Varun

Cela semble prometteur, car il ne repose pas sur des approches dépassées qui n'excellent pas pour tirer le meilleur parti du cloud (lire: crons). Data Pipeline a également des tentatives automatisées et est un service géré (sans serveur).
Felipe Alvarez

13

Que diriez-vous d'utiliser la fonctionnalité de réplication interrégionale facilement disponible sur les compartiments S3 eux-mêmes? Voici quelques articles utiles sur la fonctionnalité


Que faire si vous supprimez un fichier dans une région ne doit pas être répliqué dans l'autre?
michelem

S3 ne réplique pas les suppressions, consultez ce lien docs.aws.amazon.com/AmazonS3/latest/dev/… .
的 devrimbaris

9

On pourrait penser qu'il y aurait maintenant un moyen plus simple de simplement conserver une sorte de sauvegarde incrémentielle 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 le 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 récupération après sinistre d'un développeur junior supprimant récursivement un seau 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 bucket dans une autre région, un quotidien et un hebdomadaire, de sorte que si quelque chose de terrible se produit, vous puissiez simplement changer de région. Je n'ai pas de configuration comme celle-ci, j'ai vérifié que je n'ai pas réussi à le faire car cela demanderait un peu d'effort pour le faire, c'est pourquoi j'aurais aimé qu'il y ait une solution de stock à utiliser.


D'accord. C'est intéressant lorsque vous creusez dans S3 (même CRR - réplication intégrée), il y a de gros trous pour la reprise après sinistre. Vous ne pouvez pas, par exemple, jamais restaurer un bucket, les historiques de versions de fichiers, les métadonnées (en particulier les dates de dernière modification), etc. Tous les scénarios de récupération actuellement disponibles sont des récupérations partielles.
Paul Jowett

7

Bien que cette question ait été postée il y a quelque temps, j'ai pensé qu'il était important de mentionner la protection contre la suppression MFA avec les autres solutions. L'OP tente de résoudre la suppression accidentelle de 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 le contrôle de version du compartiment.

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

Associez -le à la réplication et au contrôle de version interrégionaux 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.


0

Si, nous avons trop de données. Si vous avez déjà un bucket, la première fois La synchronisation prendra trop de temps, Dans mon cas, j'avais 400 Go. Cela a pris 3 heures la première fois. Je pense donc que nous pouvons faire de la réplique une bonne solution pour la sauvegarde de S3 Bucket.


Je suis sur le point de déplacer environ 7 To dans un seau et j'essaie de trouver la meilleure option ... Je pense que j'ai besoin de quelque chose de mieux que la synchronisation. Je me demande si l'utilisation d'un pipeline pour copier des données vers la version GCS de glacier pourrait offrir la meilleure sécurité globale?
Brendon Whateley

AWS DataSync pourrait être une option ici.
Felipe Alvarez
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.