Jak wybrać usługę w chmurze dla kopii zapasowych

Zastanawiam się nad użyciem usługi w chmurze do utworzenia kopii zapasowej jednej z witryn mojego klienta.

Główne obawy moich (klientów) to (w malejącej kolejności ważności)

1. Ochrona IP (tajemnice handlowe, kod źródłowy), dane konta użytkownika itp
2. Gwarancja bezawaryjności oferowana przez usługodawcę (w celu zminimalizowania przestojów serwera)
3. Koszt
4. Prędkości wysyłania / pobierania

Idealnie, chciałbym usługi, która nie ma długiego remisu (tzn. Wolałbym rodzaj usługi „zgodnie z rzeczywistym użyciem”)

Chciałbym również uniknąć blokady dostawcy, gdy przejście do innej usługi jest prawie niemożliwe.

Chciałbym kilka ogólnych wskazówek na temat:

1. Jak przejść do wyboru usługodawcy
2. Kim są główni gracze w tej dziedzinie
3. zalecenie oprogramowania do: tworzenia kopii zapasowych / przywracania / oraz przesyłania / pobierania zapisanych / przywróconych plików

Oprogramowanie serwera będzie albo Ubuntu, albo Debianem (prawdopodobnie opublikuję pytanie, na którym systemie operacyjnym wybrać się jako serwer - znam już Ubuntu)

Każde rozwiązanie, które nie obejmuje szyfrowania po stronie klienta za pomocą kluczy przechowywanych przez właściciela, nie spełni pierwszego podanego wymagania (ochrona IP / bezpieczeństwo) - każdy włamanie po stronie serwera ujawnia niezaszyfrowane dane. Wyklucza to systemy synchronizacji w chmurze, takie jak Dropbox, które są właścicielami kluczy.

Aby uniknąć hostowania wszystkich ważnych kluczy szyfrowania na serwerze witryny, który w pewnym momencie również może zostać zhakowany, oto co bym zrobił:

1. Wewnętrzny serwer kopii zapasowych na własnej stronie klienta - ma klucze szyfrujące i klucze SSH dla obu innych serwerów
2. Serwer hostujący stronę internetową - może być hostem internetowym
3. Serwer lub usługa tworzenia kopii zapasowych w chmurze

Krok 1: Serwer (1) pobiera kopię zapasową z (2), więc większość włamań do serwera witryny nie naruszy kopii zapasowych. W tym momencie odbywa się szyfrowanie.

• Użyłbym rsnapshot przez SSH przy użyciu logowanie klucza opartego jak to ma minimalne wymagania dotyczące hostingowego i in-house serwera kopii zapasowych - chyba że masz dużą DB do tworzenia kopii zapasowych jest bardzo skuteczny w przepustowości i przechowuje kilka wersji serwisu, a także obsługuje usuwanie starych kopii zapasowych.
• Szyfrowanie może odbywać się za pomocą dowolnego narzędzia plik do pliku, takiego jak GPG, kopiowanie drzewa rsnapshot do innego drzewa - lub można użyć duplikatu w kroku 2, oszczędzając miejsce na dysku.
• Ważne jest „ściąganie” z serwera kopii zapasowej - jeśli serwer główny (2) ma hasła / klucze do serwera kopii zapasowych, hakerzy mogą i czasami usuwają kopie zapasowe po zhakowaniu głównego serwera (patrz poniżej). Naprawdę zaawansowane hacki mogą instalować trojany binarne SSH, które mogłyby następnie zagrozić serwerowi kopii zapasowych, ale jest to mniej prawdopodobne dla większości firm.

Krok 2: serwer (1) wypycha zaszyfrowane kopie zapasowe do (3), aby utworzyć kopię zapasową poza siedzibą. Jeśli kopie zapasowe zostały zaszyfrowane w kroku 1, możesz po prostu użyć serwera lustrzanego rsync lokalnego drzewa rsnapshot do systemu zdalnego.

• Podwójność byłaby dobrym rozwiązaniem do bezpośredniego szyfrowania i tworzenia kopii zapasowych niezaszyfrowanego drzewa rsnapshot na zdalnym serwerze. Dwulicowość za funkcje są nieco różni się rsnapshot za pomocą GPG-zaszyfrowane archiwa tar, ale zapewnia szyfrowanie kopii zapasowej na zdalnym komputerze i wymaga jedynie ssh na tym hoście (lub może korzystać z usługi Amazon S3). Duplikat nie obsługuje twardych dowiązań , więc jeśli jest to wymagane (np. Do pełnej kopii zapasowej serwera), najlepiej jest, jeśli skrypt konwertuje drzewo rsnapshot (które obsługuje twarde dowiązania) na plik tar (może tylko pliki, które mają> 1 twardy link, który będzie dość mały), aby duplikat mógł wykonać kopię zapasową pliku tar.
• Ponieważ zdalny serwer jest tylko hostem SSH, prawdopodobnie z rsync, może to być host internetowy (ale od innego dostawcy hostingu i innej części kraju) lub usługa w chmurze zapewniająca rsync i / lub SSH - patrz ta odpowiedź na temat kopii zapasowych rsync w chmurze dla jej rekomendacji bqbackup i rsync.net, chociaż nie zgadzam się z wymienioną konfiguracją tworzenia kopii zapasowych.
• Możesz używać Amazon S3 jako zdalnego serwera z duplikatem, co zapewniłoby naprawdę dobrą dostępność, chociaż być może kosztowałoby to więcej w przypadku dużych kopii zapasowych.
• Inne opcje zdalnie szyfrowanych kopii zapasowych to Boxbackup (nie tak dojrzałe, kilka fajnych funkcji) i Tarsnap (komercyjna usługa w chmurze oparta na Amazon S3 z prostym interfejsem wiersza poleceń, dobrą deduplikacją i bardzo dokładnym szyfrowaniem).
  • JungleDisk może być opcją, ale w przeszłości nie miałem z nimi świetnych doświadczeń, a ich szyfrowanie ma pewne problemy (od autora Tarsnap).

Bezpieczeństwo wszystkich różnych hostów jest ważne, dlatego należy je dostosować do profilu bezpieczeństwa klienta, tj. Analizować zagrożenia, ryzyko, wektory ataku itp. Serwer Ubuntu nie jest złym początkiem, ponieważ ma częste aktualizacje zabezpieczeń dla 5 lat, ale uwaga na bezpieczeństwo jest wymagana na wszystkich serwerach.

Ta konfiguracja zapewnia 2 niezależne kopie zapasowe, z których jedna może być wysoce dostępną usługą przechowywania w chmurze, działa w trybie ściągania, więc większość ataków na stronę internetową nie może zniszczyć kopii zapasowych w tym samym czasie i wykorzystuje dobrze sprawdzone narzędzia open source, które nie wymagają dużo administracji.

• Niezależne kopie zapasowe są krytyczne, ponieważ hakerzy naprawdę czasami usuwają wszystkie kopie zapasowe w tym samym czasie, co hakowanie witryny - w ostatnim przypadku hakerzy zniszczyli 4800 witryn, w tym kopie zapasowe poprzez zhakowanie środowiska hostingowego, a nie witryn. Zobacz także tę odpowiedź i tę .
• Przywracanie jest bardzo łatwe dzięki rsnapshot - w każdym drzewie migawek jest jeden plik na każdy plik, którego kopię zapasową utworzono, więc po prostu znajdź pliki za pomocą narzędzi Linux i rsync lub scp z powrotem na stronę. Jeśli z jakiegoś powodu lokalny serwer kopii zapasowych jest niedostępny, po prostu użyj duplikatu, aby przywrócić je z serwera kopii zapasowej w chmurze - lub możesz użyć standardowych narzędzi, takich jak GPG, rdiff i tar, aby przywrócić kopie zapasowe.

Ponieważ ta konfiguracja korzysta ze standardowego SSH i rsync, powinno być łatwiej wybrać odpowiedniego dostawcę z odpowiednimi gwarancjami dostępności, silnymi zabezpieczeniami itp. Nie musisz wiązać się z długim kontraktem, a jeśli usługa tworzenia kopii zapasowych ma katastrofalne skutki w przypadku awarii nadal masz lokalną kopię zapasową i dość łatwo możesz przejść do innej usługi tworzenia kopii zapasowych.

Jeśli chodzi o oprogramowanie, weź pod uwagę podwójność w przypadku przyrostowych kopii zapasowych z szyfrowaniem asymetrycznym i głupim odbiornikiem ( instrukcje niebędące chmurą ).

Zawsze mówię moim klientom, że najlepsze, najtańsze i najbardziej wydajne rozwiązanie do tworzenia kopii zapasowych to takie, które sam budujesz na własne potrzeby.

Kiedy buduję system dla moich klientów, używam rsync z kluczami SSH, aby obsłużyć uwierzytelnianie między serwerem A i serwerem B, gdzie serwer A zawiera dane, których kopię zapasową chcesz wykonać. Polecenie zarchiwizowania i zsynchronizowania danych znajduje się w skrypcie bash w niedostępnym katalogu, wywoływanym przez cron co godzinę (24 codziennie itp.)

Serwer zapasowy, serwer B, należy używać WYŁĄCZNIE do tworzenia kopii zapasowych. Zawsze doradzam moim klientom, aby używali wyjątkowo długiego hasła z uwierzytelnianiem za pomocą klucza SSH, aby umożliwić pobieranie kopii zapasowych i tworzenie kopii zapasowych. Czasami moi klienci potrzebują kopii zapasowych, aby były zapisywane na D dni, więc piszę kilka skryptów, aby sobie z tym poradzić (pobieram dane z aktywnego katalogu kopii zapasowych, stosuję znacznik czasu, dodajesz do archiwum w innym katalogu).

Dla małych firm / prosumentów poleciłbym Amazon Storage Service .

• Kontrola regionu (tj. Obiekty przechowywane w UE nigdy nie opuszczają UE).
• 99,9% czasu sprawności dla dowolnego cyklu rozliczeniowego
• 0,150 USD za GB przechowywanych miesięcznie
• 0,170 USD za GB pobranego pliku
• Bezpłatne przesyłanie do czerwca 2010 r., Później 0,10 USD za GB

I dość niejasna pewność, że „zapewniono mechanizmy uwierzytelniania w celu zapewnienia bezpieczeństwa danych przed nieautoryzowanym dostępem”

Podczas gdy bluenovember jest na dobrej drodze z S3, system Amazon nie jest tak naprawdę rozwiązaniem do tworzenia kopii zapasowych, jest to rozwiązanie do przechowywania surowych danych, które nadal wymaga systemu front-end do tworzenia kopii zapasowych, czy to kilka połączeń API czy pełny pakiet do zarządzania kopiami zapasowymi. Coś takiego jak JungleDisk Server Edition , która używa S3 na backendie , ale zapewnia lepszy interfejs do użycia jako rozwiązanie do tworzenia kopii zapasowych, prawdopodobnie byłoby lepsze.

Ponadto JungleDisk zapewni Ci wbudowane szyfrowanie, które musisz dodać niezależnie od tego, jak planujesz połączyć się z S3 / „chmurą”. Mają też całkiem niezłe oprogramowanie klienckie dla Linuksa.

Lubię przechowywać moją kopię zapasową w Amazon AWS i korzystam z bezpłatnego narzędzia s3cmd ( http://s3tools.org/s3cmd )

Można go zainstalować dość łatwo (Debian: apt-get install s3cmd).

Wszystko czego potrzebujesz do konta Amazon AWS do przechowywania plików na S3. Następnie proste polecenie może uruchomić twoją kopię zapasową, nawet przyrostową lub jako rozwiązanie synchronizacji, np .:

s3cmd sync /srv/backup  s3://your-bucket-name-at-amazon/

Upewnij się, że biegniesz

s3cms --configure 

najpierw wprowadź swoje dane uwierzytelniające AWS.