Używanie tar i rsync dla wysokiej dostępności


13

Mam uruchomione serwery w chmurze Ubuntu, do których nie mam bezpośredniego dostępu, ale ssh. Używam „tar” do klonowania lub w celu zapewnienia wysokiej dostępności tego serwera. Wykonałem samouczek z linku [tekst linku] [1]. Próbowałem tego instalując nowy serwer w tej samej wersji. Kiedy wyodrębniłem tar (tar -xvpzf ~ / clone.tgz -C /) w miejscu docelowym (nowy), na końcu kończy się następującymi danymi wyjściowymi podobnymi do poniższych (nie wiem, czy to błąd).

tar: var/run: time stamp 2010-11-09 17:09:11 is 7335.159880406 s in the future
tar: var/spool/postfix/usr/lib/zoneinfo: time stamp 2010-11-09 17:08:26 is 7290.159730037 s in the future
tar: var/lib: time stamp 2010-11-09 17:27:51 is 8455.159349527 s in the future
tar: usr/bin: time stamp 2010-11-09 17:28:02 is 8466.159254097 s in the future
tar: usr/share/sgml: time stamp 2010-11-09 17:27:47 is 8451.158909506 s in the future
tar: usr/share/man/man7: time stamp 2010-11-09 17:27:50 is 8454.158393583 s in the future
tar: usr/share/man/man1: time stamp 2010-11-09 17:28:02 is 8466.158166556 s in the future
tar: usr/share/man/man8: time stamp 2010-11-09 17:27:51 is 8455.158057701 s in the  future
tar: usr/share/omf/time-admin: time stamp 2010-11-09 17:27:52 is 8456.157830449 s in the future
---------------------------------------------
---------------------------------------------
---------------------------------------------

Korzystam z następującego polecenia, aby utworzyć plik tar określonych katalogów w systemie źródłowym.

tar -cvzf ~/clone.tgz --exclude ~/clone.tgz --exclude /etc/hosts --exclude /etc/hostname --exclude /etc/udev/ --exclude /etc/network/interfaces --exclude /etc/resolv.conf  /etc /home /opt /tmp /usr /var /mnt
  • Czy są jakieś środki ostrożności przed użyciem smoły? (tar jest jednorazowym tworzeniem odtąd będę używać rsync)
  • Czy powinienem dołączyć jeszcze katalog taki jak bin lub lib? - zasugeruj mi
  • Czy powinienem wykluczyć jakiś katalog? Jakbym miał problem z urządzeniem sieciowym (eth0) (nie udało się uruchomić eth0). Tak więc w powyższym poleceniu wykluczyłem „/ etc / udev /” i po tym czułem, że było dobrze W ten sposób, czy jest coś, co muszę wykluczyć z / etc / lub z dowolnego katalogu, który podałem? - zasugeruj mi.
  • Jak mogłem zaplanować rsync (przyrostowy BKP) z kombinacją ssh, aby zsynchronizować katalogi (określone w tar) ze zdalną lokalizacją (say / mnt / newdir), którą mógłbym spakować i wyodrębnić później w przypadku awarii systemu. Rsync można zaplanować do uruchomienia jako użytkownik root, ale ssh poprosi o podanie hasła. FYI, sudo jest całkowicie wyłączone, a także bezpośrednie logowanie ssh do roota jest również wyłączone.

Jeśli istnieje lepszy sposób bez szkody dla serwera, aby to osiągnąć, może zasugerować.

[1]: http://ubuntuforums.org/showthread.php ? t = 525660

Odpowiedzi:


9

Polecam zamiast tego użyć rsync, pozwoli ci to wykonać rzeczywistą synchronizację systemu z systemem bez potrzeby korzystania z plików tymczasowych. Zapewnia również korzyść z robienia przyrostowych aktualizacji, gdy trzeba zaktualizować klon.

Wykluczę tylko: / proc / / sys / dev / tmp / mnt W systemie klonowania musisz upewnić się, że pliki / etc / fstab i /boot/grub/grub.cfg są zaktualizowane o UUID partycji systemów klonowania.

Jeśli masz bazę danych taką jak mysql, musisz zachować ostrożność i zatrzymać DB przed wykonaniem kopii.


tak, dobrze przypominam, myślę, że będę musiał wykluczyć „/ etc / fstab” i „/boot/gru/grub.cfg”. Czy to jest dobre?. Proszę wstawić polecenia synchronizacji przyrostowej rsync określonych katalogów.
user3215

Ofcourse /boot/grub/grub.cfg nie jest w ogóle uwzględnione
11.11.10

Jak zaktualizować UUID systemu klonowania.
user3215,

Konieczne będzie zastąpienie identyfikatorów UUID z oryginalnych partycji w konfiguracji fstab i grub identyfikatorami UUID partycji systemu klonowania. Możesz wyświetlić listę identyfikatorów partycji za pomocą: blkid.
João Pinto,

Chcesz powiedzieć, że UUID powinny być takie same w obu systemach.
user3215,

6

Po pierwsze, wielu dostawców chmury IaaS oferuje potężne funkcje migawkowe, które rozwiązują to dość łatwo.

Na EC2, jeśli korzystasz z systemu opartego na EBS, możesz po prostu okresowo wykonywać jego migawkę. Jeśli coś okropnego stanie się z instancją źródłową, możesz przywrócić poprzednią migawkę do zupełnie nowej instancji. Jeśli chcesz zarchiwizować migawkę, możesz uruchomić inną instancję z dołączoną i użyć czegoś takiego jak tar + s3 bez negatywnego wpływu na pole produkcyjne.

Z tym podejściem wiąże się wiele problemów, które mogą nie być obecnie widoczne.

  1. Zamykacie się na jedną technologię. Jeśli działa to na Ubuntu 10.10 i chcesz przejść do wersji 11.04, musisz zaktualizować system źródłowy, a następnie wykonać migawkę. Podobnie, jeśli używasz migawek EBS EC2, potrzebujesz nowego rozwiązania, jeśli przejdziesz do chmury rackspace.
  2. Nie masz historii zmian, jeśli używasz rsync. Jeśli zmodyfikujesz coś w systemie 1, coś się zepsuje, prawdopodobnie zepsujesz również system zapasowy podczas rsync.
  3. Rsync może mieć bardzo duży wpływ na system produkcyjny.

To, czego naprawdę chcesz, to system zarządzania konfiguracją i wysoka dostępność danych.

Polecam wybrać system zarządzania konfiguracją, taki jak marionetka (w głównej części!), Kucharz lub cfengine. Rozpocznij wykonywanie całej konfiguracji w systemie zarządzania konfiguracją, a następnie możesz po prostu uruchomić system ogólny i zastosować do niego zarządzanie konfiguracją. Dodaj „etckeeper” i masz historię.

Aby uzyskać wysoką dostępność danych, rsync powinien działać i działać znacznie prościej, ponieważ wystarczy skopiować dane, które chcesz. Istnieje również drbd, aby mieć „sieć RAID1”. Nie są to zamienniki kopii zapasowych danych, które powinny obejmować historyczne migawki (czy to przez migawki urządzenia blokowego lub coś w rodzaju tar) zamiast synchronizacji z hostem odzyskiwania (co jeśli ktoś usunie wszystkie dane, które zostaną zsynchronizowane z polem odzyskiwania, usuwając je wszystkie tam też?)


2

Komunikaty są prawdopodobnie spowodowane, ponieważ nowy zegar serwera jest opóźniony w stosunku do starszego.

Jeśli klonujesz konfigurację i bazę danych menedżera pakietów (i tak jest), powinieneś sklonować / bin, / sbin i / lib, inaczej system docelowy będzie miał niespójny status. Innym podejściem będzie wykluczenie /etc/dpkg.info / etc / apt / var / lib / apt i / var / lib / dpkg i ponowna instalacja wszystkich pakietów w systemie docelowym.

Pliki w / var / dpkg i / var / apt zawierają informacje o tym, co jest zainstalowane w twoim systemie. Jeśli ich nie wykluczysz, menedżer pakietów uwierzy, że wszystkie programy i zależności w systemie nadrzędnym są zainstalowane w systemie docelowym. Ale jeśli nie skopiowałeś / bin, / sbin itp., Nie zrobią tego. Jest bardzo prawdopodobne, że coś się zepsuje przy następnej instalacji lub aktualizacji.

Aby zachować synchronizację z rsync, zawsze korzystałem z uwierzytelniania opartego na certyfikatach, a nie haseł. Jest dość łatwy w konfiguracji, pamiętam, że zrobiłem to po prostu czytając stronę podręcznika za pierwszym razem. Oto krótki przewodnik , jeśli chcesz uzyskać więcej informacji, uważam, że zasługuje na nowe pytanie.


Nie. / Var nie jest wykluczone. W powyższym poleceniu po „--exclude /etc/resolv.conf” wszystko jest zawarte w /etc/..../var / mnt. Właściwie podałem dwie spacje między resolv.conf i / etc. Tutaj się nie pokazuje.
user3215,

przepraszam, zapomniałem części linku
użytkownik3215

Ok, więc powinienem nawet dołączyć bin, sbin i lib, tutaj jest w porządku. Och .. Muszę je wykluczyć i zainstalować wszystkie pakiety.
user3215,

czy naprawdę konieczne jest wykluczenie /etc/dpkg.info / etc / apt / var / lib / apt i / var / lib / dpkg ..?
user3215

Odpowiedź zaktualizowana.
Javier Rivera,
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.