Jak wykonać kopię zapasową segmentu AWS S3 bez wersjonowania segmentu źródłowego [zamknięte]


43

Czy istnieje sposób na odzyskanie po przypadkowym usunięciu wiadra Amazon S3?

Mamy krytyczne informacje w naszych segmentach i muszę zminimalizować ryzyko przypadkowego lub złośliwego usunięcia samego segmentu.

Wiem, że mogę lokalnie zsynchronizować cały segment, ale nie jest to zbyt praktyczne, jeśli rozmiar mojego segmentu wynosi 100 GB.

Jakieś pomysły na strategie tworzenia kopii zapasowych?


Oto przewodnik strategii tworzenia kopii zapasowych S3, który napisałem: eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2
Elad Nava

Odpowiedzi:


23

Innym podejściem jest włączenie wersjonowania wersji S3 w swoim segmencie. Następnie możesz przywrócić usunięte pliki itp. Zobacz dokumentację S3, w jaki sposób to włączyć

Korzystanie z narzędzi innych firm, takich jak BucketExplorer, sprawia, że ​​praca z wersjonowaniem jest dość trywialna (w porównaniu do samodzielnego wywoływania API bezpośrednio).

Możesz także włączyć usuwanie uwierzytelniania wieloskładnikowego dla swoich segmentów S3 - co znacznie utrudnia „przypadkowe usunięcie”;)

Więcej na temat uwierzytelniania wieloskładnikowego Usuń więcej na temat usuwania
obiektów


2
Pytanie brzmi: osiągnąć to bez wersji.
Anuruddha,

13

Możesz użyć s3cmd http://s3tools.org/s3cmd

Aby wykonać kopię zapasową wiadra o nazwie mybucket

s3cmd mb s3://mybucket_backup
s3cmd --recursive cp s3://mybucket s3://mybucket_backup

3
Czy jest na to szybszy sposób? Jeśli w segmencie znajduje się n kluczy, jest co najmniej n wniosków o skopiowanie plus niektóre o umieszczenie na liście (i prawdopodobnie sprawdzenie wyników). W przypadku dużych wiader może to potrwać dość długo.
Kariem

1
Czy mógłbyś szczegółowo opisać operację tworzenia kopii zapasowej, gdy mybucket jest uszkodzony i trzeba przywrócić mybucket_backup?
Augustin Riedinger

7

To nie jest tanie rozwiązanie, ale jeśli twoje wiadra są naprawdę krytyczne, oto jak to zrobić: uruchom instancję Amazon EC2 i okresowo synchronizuj zawartość.

Amazon EC2 to ich dostawca hostingu wirtualizacji. Możesz podkręcić instancje Linuksa, Windowsa itp. I uruchomić cokolwiek zechcesz. Płacisz za godzinę, a lokalnie dostajesz dość dużą przestrzeń dyskową dla tego serwera. Na przykład używam instancji „dużego” rozmiaru, która zawiera 850 GB miejsca na dysku lokalnym.

Fajne jest to, że jest w tej samej sieci co S3, a ty masz nieograniczone transfery między S3 a EC2. Korzystam z oprogramowania Jungle Disk za 20 USD w instancji Windows EC2, która pozwala mi uzyskiwać dostęp do moich segmentów S3, tak jakby były to foldery lokalne. Następnie mogę wykonać zaplanowane pliki wsadowe, aby skopiować rzeczy z S3 na moje lokalne miejsce na dysku EC2. Możesz zautomatyzować go, aby zachować cogodzinne kopie zapasowe, jeśli chcesz lub jeśli chcesz grać, skonfiguruj JungleDisk (lub jego odpowiedniki dla systemu Linux), aby synchronizował się co godzinę. Jeśli ktoś usunie plik, masz co najmniej kilka minut na odzyskanie go z EC2. Polecam jednak regularne kopie zapasowe ze skryptami - jeśli kompresujesz je na wolumin 850 GB, łatwo jest zachować kilka dni kopii zapasowych.

Jest to bardzo przydatne w przypadku wysyłania dziennika programu SQL Server, ale widzę, w jaki sposób osiągnąłby on również twój cel.


Myślę, że możesz użyć mikro instancji i dodać tyle EBS (Elastic Block Storage), ile potrzebujesz. Może być tańszą opcją.
Shawn Vader

Właściwie nie powinieneś, ponieważ dedykowana przepustowość do i od S3 zależy od wielkości instancji EC2. Jeśli chcesz dużej przepustowości, potrzebujesz dużej (= $$$$) instancji. Mój były pracodawca dowiedział się o tym na własnej skórze.
John Cowan

6

Jednym z możliwych rozwiązań może być po prostu utworzenie „wiadra zapasowego” i skopiowanie tam poufnych informacji. Teoretycznie Twoje dane są bezpieczniejsze w S3 niż na dysku twardym.

Ponadto nie jestem pewien, czy przypadkowe usunięcie jest prawdziwym problemem, ponieważ musisz przypadkowo usunąć wszystkie klucze segmentu, zanim będziesz mógł usunąć segment.


+1, ponieważ bardzo trudno byłoby „przypadkowo” usunąć wszystko w wiadrze, a następnie usunąć również wiadro.

10
jeśli używasz narzędzia takiego jak s3cmd, nie jest to trudniejsze niż usunięcie całego drzewa katalogów za pomocąrm -rf
jberryman

Co z Amazon Glacier? Czy to jest opcja?
Tony

6

Innym możliwym rozwiązaniem jest replikacja wiadra do strefy europejskiej w S3. Może to utrzymywać wiadro po przypadkowym usunięciu wystarczająco długo, aby się zregenerować.


1
Replikacja segmentu to świetna opcja. Aby uzyskać dodatkową warstwę ochrony, użyj replikacji dla wielu kont, aby upewnić się, że naruszenie konta źródłowego nie spowoduje utraty danych.
Gareth Oakley,

6

Aby nieco zmodyfikować (doskonałą) odpowiedź Brenta; nie powinieneś utrzymywać działania instancji. Utwórz EC2 AMI, który ściąga dane, synchronizuje je z woluminem EBS, wykonuje migawkę tego woluminu i wyłącza się.

Wolumin można również uruchomić sam, ale jego wykonanie powinno być wystarczające do wykonania kopii zapasowej. Jeśli Twój niestandardowy interfejs AMI wykonuje to wszystko (w tym samoczynnie się wyłącza po zakończeniu) bez interakcji, skrypt „kopii zapasowej” musi po prostu wykonać polecenie „ec2run -n 1 -t m1.small ami-” i odpalić i zapomnieć.


Podoba mi się ten pomysł, że inni, jest to bardziej rozsądne i tańsze rozwiązanie.
BMW
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.