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
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.
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ż?)
źródło
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.
źródło