Strategie tworzenia kopii zapasowych dla zasobnika AWS S3


92

Szukam porady lub najlepszych praktyk, aby utworzyć kopię zapasową wiadra S3.
Celem tworzenia kopii zapasowych danych z S3 jest zapobieganie utracie danych z następujących powodów:

  1. Problem S3
  2. problem gdzie przypadkowo usunąłem te dane z S3

Po pewnym zbadaniu widzę następujące opcje:

  1. Użyj wersji http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
  2. Skopiuj z jednego zasobnika S3 do drugiego za pomocą AWS SDK
  3. Kopia zapasowa do Amazon Glacier http://aws.amazon.com/en/glacier/
  4. Kopia zapasowa na serwerze produkcyjnym, na którym jest tworzona kopia zapasowa

Jaką opcję powinienem wybrać i jak bezpieczne byłoby przechowywanie danych tylko na S3? Chcesz poznać swoje opinie.
Kilka przydatnych linków:


Odpowiedzi:


63

Pierwotnie opublikowane na moim blogu: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

Okresowo synchronizuj swoje wiadro S3 z serwerem EC2

Można to łatwo osiągnąć, wykorzystując wiele narzędzi wiersza poleceń, które umożliwiają synchronizację zdalnego zasobnika S3 z lokalnym systemem plików.

s3cmd
Początkowo s3cmdwyglądał niezwykle obiecująco. Jednak po wypróbowaniu go na moim ogromnym wiadrze S3 - nie udało się skalować, błędnie z rozszerzeniem Segmentation fault. Jednak działało dobrze na małych wiaderkach. Ponieważ nie działało to w przypadku dużych łyżek, postanowiłem znaleźć alternatywę.

s4cmd
Nowsza, wielowątkowa alternatywa dla s3cmd. Wyglądało to jeszcze bardziej obiecująco, jednak zauważyłem, że ponownie pobierał pliki, które były już obecne w lokalnym systemie plików. Nie takiego zachowania oczekiwałem po poleceniu synchronizacji. Powinien sprawdzić, czy zdalny plik już istnieje lokalnie (sprawdzanie skrótu / rozmiaru pliku byłoby niezłe) i pominąć go podczas następnej synchronizacji w tym samym katalogu docelowym. Otworzyłem problem ( bloomreach / s4cmd / # 46 ), aby zgłosić to dziwne zachowanie. W międzyczasie postanowiłem znaleźć inną alternatywę.

awscli
I wtedy znalazłem awscli. To jest oficjalny interfejs wiersza poleceń Amazon do interakcji z różnymi usługami w chmurze, w tym S3.

AWSCLI

Zapewnia przydatne polecenie synchronizacji, które szybko i łatwo pobiera zdalne pliki zasobnika do lokalnego systemu plików .

$ aws s3 sync s3: // nazwa-twojego-wiadra / home / ubuntu / s3 / nazwa-twojego-wiadra /

Korzyści:

  • Skalowalne - obsługuje duże łyżki S3
  • Wielowątkowy - synchronizuje pliki szybciej dzięki wykorzystaniu wielu wątków
  • Inteligentne - synchronizuje tylko nowe lub zaktualizowane pliki
  • Szybki - dzięki wielowątkowości i inteligentnemu algorytmowi synchronizacji

Przypadkowe usunięcie

Dogodnie syncpolecenie nie usunie plików w folderze docelowym (lokalny system plików), jeśli brakuje ich w źródle (zasobnik S3) i odwrotnie. Jest to idealne rozwiązanie do tworzenia kopii zapasowych S3 - w przypadku usunięcia plików z zasobnika, ponowna synchronizacja nie spowoduje ich usunięcia lokalnie. A jeśli usuniesz plik lokalny, nie zostanie on również usunięty z zasobnika źródłowego.

Konfigurowanie awscli na Ubuntu 14.04 LTS

Zacznijmy od instalacji awscli. Istnieje kilka sposobów, aby to zrobić, jednak uważam, że to najłatwiej zainstalować go za pomocą apt-get.

$ sudo apt-get install awscli

Konfiguracja

Następnie musimy skonfigurować za awsclipomocą naszego identyfikatora klucza dostępu i tajnego klucza, które należy uzyskać od IAM , tworząc użytkownika i dołączając zasady AmazonS3ReadOnlyAccess . Uniemożliwi to również Tobie lub każdemu, kto uzyska dostęp do tych poświadczeń, usunięcie plików S3. Pamiętaj, aby wprowadzić swój region S3, taki jak us-east-1.

$ aws configure

aws configure

Przygotowanie

Przygotujmy lokalny katalog kopii zapasowych S3, najlepiej w formacie /home/ubuntu/s3/{BUCKET_NAME}. Pamiętaj, aby zastąpić {BUCKET_NAME}rzeczywistą nazwą zasobnika.

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

Synchronizacja początkowa

Zsynchronizujmy zasobnik po raz pierwszy za pomocą następującego polecenia:

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

Zakładając, że zasobnik istnieje, poświadczenia i region AWS są poprawne, a folder docelowy jest prawidłowy, awsclirozpocznie się pobieranie całego zasobnika na lokalny system plików.

W zależności od rozmiaru wiadra i połączenia internetowego może to zająć od kilku sekund do godzin. Kiedy to zrobisz, skonfigurujemy automatyczne zadanie cron, aby zachować aktualność lokalnej kopii zasobnika.

Konfigurowanie zadania Cron

Śmiało i utwórz sync.shplik w /home/ubuntu/s3:

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

Skopiuj i wklej następujący kod do sync.sh:

#! / bin / sh

# Powtórz aktualną datę i godzinę

Echo '-----------------------------'
data
Echo '-----------------------------'
Echo ''

# Inicjalizacja skryptu Echo
echo „Synchronizowanie zdalnego zasobnika S3 ...”

# Właściwie uruchom polecenie synchronizacji (zamień {BUCKET_NAME} na nazwę zasobnika S3)
/ usr / bin / aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# Zakończenie skryptu echa
echo „Synchronizacja zakończona”

Pamiętaj, aby dwukrotnie zastąpić {BUCKET_NAME} nazwą swojego zasobnika S3 w całym skrypcie.

Porada dla profesjonalistów: Powinieneś użyć /usr/bin/awslinku do pliku awsbinarnego, ponieważ crontabwykonuje polecenia w ograniczonym środowisku powłoki i nie będzie w stanie samodzielnie znaleźć pliku wykonywalnego.

Następnie upewnij się, chmodże skrypt może zostać wykonany przez crontab.

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

Spróbujmy uruchomić skrypt, aby upewnić się, że faktycznie działa:

$ /home/ubuntu/s3/sync.sh

Wynik powinien być podobny do tego:

sync.sh wyjście

Następnie edytujmy bieżącego użytkownika, crontabwykonując następujące polecenie:

$ crontab -e

Jeśli uruchamiasz go po raz pierwszy crontab -e, musisz wybrać preferowany edytor. Polecam wybrać, nanoponieważ jest to najłatwiejsze do pracy dla początkujących.

Częstotliwość synchronizacji

Musimy powiedzieć, crontabjak często uruchamiać nasz skrypt i gdzie znajduje się skrypt w lokalnym systemie plików, pisząc polecenie. Format tego polecenia jest następujący:

mh dom mon dow polecenie

Następujące polecenie konfiguruje crontaburuchamianie sync.shskryptu co godzinę (określone przez parametry minut: 0 i godzina: *) i przesyła dane wyjściowe skryptu do sync.logpliku w naszym s3katalogu:

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

Powinieneś dodać tę linię na dole crontabedytowanego pliku. Następnie kontynuuj i zapisz plik na dysku, naciskając Ctrl + W, a następnie Enter . Następnie można wyjść nanowciskając Ctrl + X . crontabbędzie teraz uruchamiać zadanie synchronizacji co godzinę.

Wskazówka dla profesjonalistów: możesz sprawdzić, czy godzinowe zadanie cron jest pomyślnie wykonywane /home/ubuntu/s3/sync.log, sprawdzając, sprawdzając jego zawartość pod kątem daty i godziny wykonania oraz sprawdzając dzienniki, aby zobaczyć, które nowe pliki zostały zsynchronizowane.

Wszystko gotowe! Twój zasobnik S3 będzie teraz automatycznie synchronizowany z serwerem EC2 co godzinę i powinieneś być gotowy. Należy pamiętać, że z biegiem czasu, gdy Twój zasobnik S3 będzie się powiększał, może być konieczne zwiększenie rozmiaru wolumenu EBS serwera EC2, aby pomieścić nowe pliki. Zawsze możesz zwiększyć rozmiar wolumenu EBS, postępując zgodnie z tym przewodnikiem .


Zostawiłem pytanie na Twoim blogu, ale zastanawiałem się, czy istnieje sposób na synchronizację metadanych?
Devology Ltd

@Devology Ltd, Niestety nie miałem okazji pracować z metadanymi obiektu S3. Z szybkiego wyszukiwania w Google nie wygląda na to, że awsclipodpory synchronizują to automatycznie w aws s3 syncpoleceniu. Wygląda na to, że być może trzeba będzie to zaimplementować ręcznie.
Elad Nava

Dzięki @Ekad Nava - doceniam, że potwierdziłeś to, w co wierzyłem.
Devology Ltd

1
To fantastyczne dzięki @EladNava za udostępnienie, nadal aktualne w 2020 roku!
user1130176

ta odpowiedź nie pasuje, gdy masz w niej miliony plików. Staje się to bardzo kosztowne, powolne, a czasem niemożliwe - z powodu ograniczeń systemu plików.
Psychozoic

30

Biorąc pod uwagę powiązany link, który wyjaśnia, że ​​S3 ma trwałość 99,999999999%, odrzuciłbym Twoje obawy # 1. Poważnie.

Teraz, jeśli # 2 jest prawidłowym przypadkiem użycia i prawdziwym problemem dla ciebie, zdecydowanie trzymałbym się opcji # 1 lub # 3. Który z nich? To naprawdę zależy od kilku pytań:

  • Czy potrzebujesz innych funkcji wersjonowania, czy tylko po to, aby uniknąć przypadkowego nadpisania / usunięcia?
  • Czy dodatkowy koszt związany z wersjonowaniem jest przystępny?
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. Zgadzasz się z tym?

O ile twoje wykorzystanie pamięci nie jest naprawdę duże, trzymałbym się wersji wiadro. W ten sposób nie będziesz potrzebować żadnego dodatkowego kodu / przepływu pracy do tworzenia kopii zapasowych danych w Glacier, innych zasobnikach lub nawet na jakimkolwiek innym serwerze (co jest naprawdę złym wyborem IMHO, zapomnij o tym).


4
@SergeyAlekseev Jeśli Glacier to coś, co zadziała dla Ciebie, bardzo szybko skonfigurujesz regułę cyklu życia dla wiadra, który automagicznie archiwizuje twoje pliki na lodowiec. Nadal będą się pojawiać w zasobniku (w interfejsie internetowym), ale klasa pamięci zmieni się ze standardowej na lodowcową. Przenoszę przetworzone pliki z mojego głównego zasobnika do zasobnika „gotowego”, a zasobnik gotowych ma regułę cyklu życia, która archiwizuje wszystko, co jest starsze niż 1 dzień. Są to pliki danych, których prawdopodobnie już nigdy więcej nie dotknę, ale muszę zachować dla klienta.
Dan,

28
Myślę, że 99,999999999% nie jest wystarczającym powodem, aby być pełnym stosem aws w zakresie przechowywania / tworzenia kopii zapasowych. Nie mówię o pozostałym 0,0000000001%, ale bardziej, jeśli wydarzy się coś wysoce nieoczekiwanego, niewygodne jest trzymanie gdzieś całej firmy. Nieoczekiwanie może to oznaczać, że Stany Zjednoczone idą na wojnę do konkretnego kraju, Amazon został całkowicie zhakowany (por. Sony) itp.
Augustin Riedinger

11
Wrócę do @AugustinRiedinger na ten temat: „Kwestia S3” może być z definicji czymś, czego nie znasz (np. Kwestie rządowe), co może unieważnić hipotezy, na których oparte są numery SLA S3, takie jak 99,99…. Kiedy robisz cokolwiek długoterminowego, w tym tworzenie kopii zapasowych danych, dywersyfikacja jest dobrą praktyką, jeśli nie, powinna być warunkiem wstępnym
lajarre

2
Zdecydowanie zgadzam się, że twoje punkty są ważne. Ale opierając się na opcjach podanych przez PO (prawie wszystkie z nich, w tym alternatywy AWS dla problemu), nie sądzę, że „problem S3” byłby tak szeroki, jak wy się rozszerzacie. Dobrze jest jednak widzieć szersze myśli.
Viccari

4
Stara odpowiedź, ale czuję, że muszę wspomnieć o ostatnich (-awych) wydarzeniach. „W dniu, w którym Amazon zepsuł sieć”, technik przypadkowo usunął ogromną część swoich serwerów S3. Nawet w ciągu tych 24 godzin problemem była dostępność. Nie utrata danych. Nie było absolutnie żadnej utraty danych, nawet biorąc pod uwagę dużą liczbę usuwanych serwerów, a mimo to udało im się spełnić warunki umowy SLA
Oberst,

14

Możesz wykonać kopię zapasową danych S3, korzystając z następujących metod

  1. Zaplanuj proces tworzenia kopii zapasowej za pomocą linii danych AWS, można to zrobić na 2 sposoby wymienione poniżej:

    za. Korzystanie z copyActivity z datapipeline, za pomocą którego można kopiować z jednego segmentu s3 do drugiego segmentu s3.

    b. Użycie ShellActivity datapipeline i poleceń „S3distcp” w celu wykonania rekurencyjnej kopii rekurencyjnych folderów s3 z zasobnika do innego (równolegle).

  2. Używaj wersjonowania w zasobniku S3, aby zachować różne wersje danych

  3. Użyj lodowca do tworzenia kopii zapasowych danych (użyj go, gdy nie musisz szybko przywracać kopii zapasowej do oryginalnych zasobników (odzyskanie danych z lodowca zajmuje trochę czasu, ponieważ dane są przechowywane w formacie skompresowanym) lub gdy chcesz zapisać pewne koszty, unikając użycia innego zasobnika s3 do tworzenia kopii zapasowych), tę opcję można łatwo ustawić za pomocą reguły cyklu życia zasobnika s3, z którego chcesz wykonać kopię zapasową.

Opcja 1 może zapewnić większe bezpieczeństwo, powiedzmy w przypadku przypadkowego usunięcia oryginalnego zasobnika s3, a kolejną korzyścią jest to, że możesz przechowywać kopię zapasową w folderach datewise w innym zasobniku s3, dzięki czemu wiesz, jakie dane posiadałeś w określonym dniu i możesz przywrócić kopię zapasową z określoną datą. Wszystko zależy od twojego przypadku użycia.


@David: Jak zasugerował David w swoim rozwiązaniu poniżej, może istnieć skrypt, który codziennie lub co tydzień tworzy kopię zapasową zasobnika s3. Można to łatwo osiągnąć w moim pierwszym punkcie (linia danych AWS - która daje możliwość planowania procesu tworzenia kopii zapasowych - codziennie , co tydzień itp.). Poleciłbym poszukać w aws datapipeline.
Varun

Jest to obiecujące, ponieważ nie opiera się na przestarzałych podejściach, które nie zapewniają doskonałego wykorzystania chmury (czytaj: crony). Data Pipeline ma również zautomatyzowane ponawianie i jest usługą zarządzaną (bezserwerową).
Felipe Alvarez

13

A co powiesz na użycie łatwo dostępnej funkcji replikacji między regionami w samych łyżkach S3? Oto kilka przydatnych artykułów na temat tej funkcji


Co się stanie, jeśli usuniesz plik w jednym regionie, nie powinien on być replikowany w drugim?
michelem

S3 nie replikuje usunięć, sprawdź ten link docs.aws.amazon.com/AmazonS3/latest/dev/… .
ᐅ devrimbaris

9

Można by pomyśleć, że do tej pory byłby łatwiejszy sposób, aby po prostu przechowywać jakieś przyrostowe kopie zapasowe w regionie różnic.

Wszystkie powyższe sugestie nie są tak naprawdę prostymi ani eleganckimi rozwiązaniami. Naprawdę nie uważam lodowca za opcję, ponieważ uważam, że jest to bardziej rozwiązanie archiwalne niż rozwiązanie do tworzenia kopii zapasowych. Kiedy myślę o kopii zapasowej, myślę o odzyskiwaniu po awarii od młodszego programisty, który rekursywnie usuwa wiadro lub być może exploit lub błąd w twojej aplikacji, który usuwa rzeczy z s3.

Dla mnie najlepszym rozwiązaniem byłby skrypt, który po prostu tworzy kopie zapasowe jednego zasobnika w innym regionie, raz dziennie i raz co tydzień, tak że jeśli wydarzy się coś strasznego, możesz po prostu zmienić region. Nie mam takiej konfiguracji, przyjrzałem się, że po prostu nie zabrałem się za zrobienie tego, ponieważ zrobienie tego wymagałoby trochę wysiłku, dlatego chciałbym, aby było jakieś rozwiązanie zapasowe do użycia.


Zgoda. Interesujące jest to, że kiedy zagłębisz się w S3 (nawet wbudowaną replikację CRR), pojawiają się duże dziury do odzyskiwania po awarii. Nie można na przykład nigdy przywrócić zasobnika, historii wersji plików, metadanych (zwłaszcza dat ostatniej modyfikacji) itp. Wszystkie obecnie dostępne scenariusze odzyskiwania to częściowe odzyskiwanie.
Paul Jowett

7

Chociaż to pytanie zostało opublikowane jakiś czas temu, pomyślałem, że ważne jest, aby wspomnieć o ochronie przed usunięciem MFA z innymi rozwiązaniami. OP próbuje rozwiązać problem przypadkowego usunięcia danych. Uwierzytelnianie wieloskładnikowe (MFA) manifestuje się tutaj w dwóch różnych scenariuszach -

  1. Trwałe usuwanie wersji obiektów - Włącz usuwanie MFA w wersji zasobnika.

  2. Przypadkowe usunięcie samego zasobnika - skonfiguruj zasadę zasobnika, która zabrania usuwania bez uwierzytelniania MFA.

Połącz z replikacją między regionami i wersjonowaniem, aby zmniejszyć ryzyko utraty danych i ulepszyć scenariusze odzyskiwania.

Oto bardziej szczegółowy post na blogu na ten temat.


0

Jeśli mamy za dużo danych. Jeśli masz już wiadro to za pierwszym razem Synchronizacja zajmie zbyt dużo czasu, w moim przypadku miałem 400 GB. Za pierwszym razem zajęło to 3 godziny. Myślę więc, że możemy sprawić, że replika jest dobrym rozwiązaniem do tworzenia kopii zapasowych S3 Bucket.


Zamierzam przenieść około 7 TB do wiadra i próbuję znaleźć najlepszą opcję ... Myślę, że potrzebuję czegoś lepszego niż synchronizacja. Zastanawiam się, czy użycie potoku do kopiowania danych do wersji GCS lodowca może zapewnić najlepsze ogólne bezpieczeństwo?
Brendon Whateley

AWS DataSync może być tutaj opcją.
Felipe Alvarez
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.