Przywaracanie systemu na serwerze dedykowanym

[Bastian]

Witam.
Mam serwer dedykowany. Instaluję na nim Debiana, pożądane usługi i je konfiguruje. Serwer śmiga sobie miło, aż tu któregoś dnia ktoś się włamuje i zaczyna mieszać, lub jakiś ,,rootkit''. Chciałbym mieć możliwość przywrócenia stanu systemu do momentu tej świeżej instalacji ze skonfigurowanymi usługami, tak aby po wgraniu kopii zapasowych baz danych system chodził bezproblemowo dalej. Pytanie, jak coś takiego uzyskać?

Jest poradnik kolegi Akkona, ale tam jest mowa o przenoszeniu na inną partycję, a ja raczej musiałbym instalować system od nowa i co najwyżej przywracać obraz, ale nie wiem czy tak w ogóle się da. A może macie jakieś lepsze propozycje. Jeśli chodzi o wirtualizacje to nie znam się na tym w ogóle.

[Pacek]

Wirtualizacja jest moim zdaniem najlepszym rozwiązaniem, ponieważ umożliwia przeniesienie Twojego systemu operacyjnego na dowolną platformę sprzętową. Poza tym wirtualizacja umożliwia tworzenie tzw. migawki (ang. snapshot), czyli punktu przywracania. Dobre jest to, że np. w czasie konfiguracji coś się spaprze, to do takiego punktu można zawsze wrócić. Jeżeli chodzi o wirtualizację to można skorzystać z np. z darmowego VMWare Server.
Nie wiem co masz na myśli pisząc "obraz". Czy to jest archiwum tar, czy jakiś plik ISO? Ja w pracy robiłem procedurę kopii zapasowej i przywracania serwera. U mnie robi się to tak:

1. Zrobić kopię zapasową baz danych mysql przy pomocy mysqlhotcopy oraz mysqldump (do folderu np. /mysql_backup)
2. Wykonać archiwum tar (gz, bz2) wszystkiego co jest na dysku bez /boot i podfolderów zawartych w /var/lib/mysql.
3. Wykonać instalację Debiana z płyty "netinstall".
4. Przywrócić wszystko z pliku tar (gz,bz2).
5. Poprawić plik /etc/fstab pod nową instalację (np. jak przenosimy na inny serwer lub inaczej podzielony na partycje).
6. Skopiować bazy danych z /mysql_backup do /var/lib/mysql.
7. Zrobić restart serwera.
8. Zweryfikować, czy wszystkie usługi się uruchamiają.

Adnotacje do pkt.1 i 2
Nie zaleca się kopiowania bazy danych podczas pracy serwera mysql bo można doprowadzić do rozspójnienia bazy danych. Dlatego należy zrobić to tymi dwoma narzędziami. Samo mysqdump nie wystarczy, ponieważ po przywróceniu systemu z archiwum nie będzie bazy danych mysql (zawierającej użytkowników, hasła itp.) i nie będzie można podłączyć się do myslq'a i przywrócić pozostałych baz danych z pliku wykonanego przez mysqldump. Dlatego trzeba skopiować bazy wykonane mysqlhotcopy, a później można ewentualnie przywracać z pliku wykonanego przez mysqldump.

[Bastian]

Bardzo cenne uwagi. Mam zatem kilka pytań:

Wirtualizacja jest moim zdaniem najlepszym rozwiązaniem, ponieważ umożliwia przeniesienie Twojego systemu operacyjnego na dowolną platformę sprzętową. Poza tym wirtualizacja umożliwia tworzenie tzw. migawki (ang. snapshot), czyli punktu przywracania. Dobre jest to, że np. w czasie konfiguracji coś się spaprze, to do takiego punktu można zawsze wrócić. Jeżeli chodzi o wirtualizację to można skorzystać z np. z darmowego VMWare Server.

No właśnie albo z Xen, tyle, że kompletnie nie wiem jak się do tego zabrać. Tzn. aby efekt końcowy był taki, iż system będzie działał na serwerze wirtualnym, a jak się sknoci to będe mógł przywrócić go stanu początkowego (już skonfigurowanego z wszystkim zainstalowanym) poprzez uruchomienie drugiego serwera wirtualnego i podegrania systemu.

Nie wiem co masz na myśli pisząc "obraz". Czy to jest archiwum tar, czy jakiś plik ISO?

Chodzi o plik *.img.gz, który wg poradnika Akkona powstanie.

Ja w pracy robiłem procedurę kopię zapasową i przywracanie z kopii serwera. U mnie robi się to tak:

1. Zrobić kopię baz danych mysql przy pomocy mysqlhotcopy oraz mysqldump (do folderu np. /mysql_backup)

U mnie dotyczy to zarówno mysql jak i postgresa. Generalnie jeśli chodzi o bazy to polecenie dump struktury i zawartości. Potem sobie odtwarzam, tworząc je na nowo. Mniej eleganckie ale chyba może być

2. Wykonać archiwum tar (gz, bz2) wszystkiego co jest na dysku bez /boot i podfolderów zawartych w /var/lib/mysql

A jeśli system stoi na wielu partycjach (/var/, /usr, /home, /dev, /boot)? Tworzysz wtedy archiwa do każdej partycji?

3. Wykonać instalację Debiana z dystrybucji sieciowej

A po prostu z płyty nie można?

4. Przywrócić wszystko z pliku tar (gz,bz2)

Czyli przy instalacji tworze dokładnie takie same partycje jak w systemie pierwotnym i na nich przywracam odpowiednie archiwa.

5. Poprawić plik /etc/fstab pod nową instalację (np. jak przenosimy na inny serwer lub inaczej podzielony na partycje).

6. Skopiować bazy danych z /mysql_backup do /var/lib/mysql

lub tam gdzie trzyma się klaster.

7. Zrobić restart serwera
8. Zweryfikować, czy wszystkie usługi się uruchamiają

Adnotacje do pkt.1 i 2
Nie zaleca się kopiowania bazy danych podczas pracy serwera mysql bo można doprowadzić do rozspójnienia bazy danych.
Dlatego należy zrobić to tymi dwoma narzędziami. Samo mysqdump nie wystarczy, ponieważ po przywróceniu systemu z archiwum nie będzie bazy danych mysql (zawierającej użytkowników, hasła itp.) i nie będzie można podłączyć się do myslq'a i przywrócić pozostałych baz danych z pliku wykonanego przez mysqldump. Dlatego trzeba skopiować bazy wykonane mysqlhotcopy, a później można ewentualnie przywracać z pliku wykonanego przez mysqldump

Nie bardzo rozumiem. Nie można z pomocą dump przenieść bazy danych, i na nowym systemie najpierw utworzyć użytkownika i na niego wgrać tą bazę danych?

Czyli:

Kod: Zaznacz cały

mysqldump --u [I]użytkownik[/I] -p  [I]hasło[/I] --add-drop-table [I]baza[/I]

A potem stworzyć użytkownika i:

Kod: Zaznacz cały

mysql -u [I]użytkownik[/I] -p [B]hasło[/B] < zdumowana_baza.sql

Przysięgam, że tak robiłem i działa.

[Pacek]

No właśnie albo z Xen, tyle, że kompletnie nie wiem jak się do tego zabrać. Tzn. aby efekt końcowy był taki, iż system będzie działał na serwerze wirtualnym, a jak się sknoci to będe mógł przywrócić go stanu początkowego (już skonfigurowanego z wszystkim zainstalowanym) poprzez uruchomienie drugiego serwera wirtualnego i podegrania systemu.

To żaden problem. Maszynę wirtualną zgrywasz jako plik (mówiąc w uproszczeniu) na nową maszynę i uruchamiasz. I w zasadzie na tym zaczyna i kończy się cała filozofia.

U mnie dotyczy to zarówno mysql jak i postgresa. Generalnie jeśli chodzi o bazy to polecenie dump struktury i zawartości. Potem sobie odtwarzam, tworząc je na nowo. Mniej eleganckie ale chyba może być

Nie bardzo rozumiem. Nie można z pomocą dump przenieść bazy danych, i na nowym systemie najpierw utworzyć użytkownika i na niego wgrać tą bazę danych?

No mysqldump jest bardzo eleganckie. Pamiętaj o tym, że najlepiej jest wykluczyć pliki baz danych mysql'a z archiwizacji (katalog /var/lib/mysal/*) i robić kopię baz mysqlhotcoppy, albo zatrzymywać usługę mysql'a i wtedy kopiowac te pliki, żeby uniknąć uszkodzenia baz. Jeżeli wykluczysz foldery baz danych (var/lib/mysal/*) z kopiowania, to po przywróceniu nie będziesz miał bazy danych mysql niezbędnej do uruchomienia mysqld i wtedy nie będziesz mógł przywrócić bazy przy użyciu :

Kod: Zaznacz cały

mysql - u user_name -p your_password database_name < file_name.sql

ponieważ nie będzie żadnego użytkownika ani hasła w bazie "mysql", bo tej bazy w ogóle nie będzie.
Jeżeli chodzi o postgresa to nie miałem z nim do czynienia, ale podejrzewam, że ma podobne mechanizmy. Jeżeli jednak nie, to zawsze można zrobić zatrzymanie usługi i skopiowanie chociaż wewnętrznej bazy danych postgresa. Resztę baz można zrobić przez wbudowane narzędzie dump i restore.

A jeśli system stoi na wielu partycjach (/var/, /usr, /home, /dev, /boot)? Tworzysz wtedy archiwa do każdej partycji?

u mnie jest kilka partycji, ale wszystko wrzucam w jedno archiwum. Zawsze możesz wybrać, co chcesz wyodrębnić z archiwum. Zresztą jak zainstalujesz nowy system i zrobisz układ partycji, to przecież pliki przywracane z archiwum trafią jakby na to samo miejsce. Dobrze jest jednak zachować stara wersje /etc/fstab, bo czasami na nowym serwerze masz inaczej nazwane dyski.

A po prostu z płyty nie można?

Wersja sieciowa jest też z płyty Ona najmniej zajmuje i nie ma konieczności ściągania całych 4GB. I tak instaluje się tylko "system podstawowy" bez żadnych wodotrysków. Jednak odpowiadając na pytanie: oczywiście, że można

Czyli przy instalacji tworze dokładnie takie same partycje jak w systemie pierwotnym i na nich przywracam odpowiednie archiwa.

Linux jest o tyle tolerancyjny, że każdą partycję możesz sobie przenieść gdziekolwiek i potem zamontować. Może taki mały przykład. Kończy Ci się miejsce np na partycji logów /var/log. Podłączasz nowy dysk na USB i go montujesz w /mnt/hdd. Następnie przenosisz logi na niego ze starej partycji. Odmontowujesz /mnt/hdd, odmontowujesz stare /var/log i zamontowujesz sobie dysk USB jako /var/log. Modyfikujesz /etc/fstab, żeby wskazywało na dysk USB i masz na daną chwilę logi wrzucone na inny dysk. Także w tej kwestii układ partycji nie musi być identyczny z tym co było na serwerze wcześniejszym. Należy jednak dopilnować, aby plik /etc/fstab wskazywał prawidłowe partycje.

Przysięgam, że tak robiłem i działa. (dot. mysql)

Działa, kiedy masz pracującego mysql'a. Jeżeli przywrócisz wszystko z archiwum (a w nim nie będzie baz mysql'a z folderu /var/lib/mysql), to serwer mysql sie nie uruchomi.

[Bastian]

To żaden problem. Maszynę wirtualną zgrywasz jako plik (mówiąc w uproszczeniu) na nową maszynę i uruchamiasz. I w zasadzie na tym zaczyna i kończy się cała filozofia.

No tak, z tego co opisujesz przypomina to zabawę z Virtualboxem. Jednak wg tego to trzeba trochę się namęczyć żeby ustawić maszyny wirtualne, a jeszcze nie wiem jak potem "wgrywać/tworzyć" maszyny wirtualne. Zapomniałem wspomnieć, że w moim przypadku potrzebowałbym raczej wirtualizacji niż metody, którą opisałeś, bo potrzebuje po prostu drugiego serwera nazwijmy "lustrzanego", którego mogę użyć nie tylko do przywrócenia systemu, ale uruchomienia go równolegle (np. do testowania środowiska). I czy jeśli stworzę taką kopię maszyny wirtualnej, na której już chodzą np. bazy danych, to przy uruchamianiu drugiej tej samej maszyny to będą tam chodzące te same bazy danych?

No mysqldump jest bardzo eleganckie. Pamiętaj o tym, że najlepiej jest wykluczyć pliki baz danych mysql'a z archiwizacji (katalog /var/lib/mysal/*) i robić kopię baz mysqlhotcoppy, albo zatrzymywać usługę mysql'a i wtedy kopiowac te pliki, żeby uniknąć uszkodzenia baz. Jeżeli wykluczysz foldery baz danych (var/lib/mysal/*) z kopiowania, to po przywróceniu nie będziesz miał bazy danych mysql niezbędnej do uruchomienia mysqld i wtedy nie będziesz mógł przywrócić bazy przy użyciu:

Kod: Zaznacz cały

mysql - u user_name -p your_password database_name < file_name.sql 

ponieważ nie będzie żadnego użytkownika ani hasła w bazie "mysql", bo tej bazy w ogóle nie będzie.

Czyli jeśli chcę zrobić kopię z bazy mysql to powinienem najpierw wykonać:

Kod: Zaznacz cały

mysqlhotcopy --user={username} --password={password} {database} {path}

Co mam wtedy podać jako ścieżkę (path)?

A następnie:

Kod: Zaznacz cały

mysql - u user_name -p your_password database_name < file_name.sql

[Pacek]

No tak, z tego co opisujesz przypomina to zabawę z Virtualboxem. Jednak wg tego to trzeba trochę się namęczyć żeby ustawić maszyny wirtualne, a jeszcze nie wiem jak potem "wgrywać/tworzyć" maszyny wirtualne. Zapomniałem wspomnieć, że w moim przypadku potrzebowałbym raczej wirtualizacji niż metody, którą opisałeś, bo potrzebuje po prostu drugiego serwera nazwijmy "lustrzanego", którego mogę użyć nie tylko do przywrócenia systemu, ale uruchomienia go równolegle (np. do testowania środowiska). I czy jeśli stworzę taką kopię maszyny wirtualnej, na której już chodzą np bazy danych, to przy uruchamianiu drugiej tej samej maszyny to będą tam chodzące te same bazy danych?

Ja akurat używałem VMWare Server więc co do Xena to nie będę się wypowiadał. Może kiedyś wypróbuję to wtedy dam znać. W przypadku VMWare tworzysz kopię, wrzucasz na drugi serwer, który ma zainstalowane VMWare, rejestrujesz maszynę w VMWare i ją uruchamiasz. Nie ma w tym jakiejś wielkiej filozofii.

Czyli jeśli chcę zrobić kopię z bazy mysql to powinienem najpierw wykonać:

Kod: Zaznacz cały

mysqlhotcopy --user={username} --password={password} {database} {path}

Dopóki działa Ci mysql, to kopie zapasową możesz robić mysqldump i wtedy nie ma problemów z przywróceniem. Schody zaczynają się wtedy, jak tych baz nie ma? Zgodnie z tym co opisałem wcześniej). Jeżeli chodzi o parametr path w mysqlhotcopy, to podajesz katalog, do którego bazy danych zostaną skopiowane (np. /backup). Katalog musi istnieć. Chodzi o to, że mysqlhotcopy robi bezpieczną kopię baz danych podczas pracy serwera mysql. Zwykłe kopiowanie baz danych może je uszkodzić.

A następnie:

Kod: Zaznacz cały

mysql -u user_name -p your_password database_name < file_name.sql

Tak może być

[Bastian]

Ja akurat używałem VMWare Server więc co do Xena to nie będę się wypowiadał. Może kiedyś wypróbuję to wtedy dam znać. W przypadku VMWare tworzysz kopię, wrzucasz na drugi serwer, który ma zainstalowane VMWare, rejestrujesz maszynę w VMWare i ją uruchamiasz. Nie ma w tym jakiejś wielkiej filozofii

No tak, ale fizycznie mam jeden tylko serwer. Tak więc w moim przypadku (kiedy jedna maszyna zostanie zainfekowana bądź przejęta..) nie wrzucam na drugi serwer tej kopii maszyny, tylko tworzę nową instancję w ramach tego samego VMWare i jadę dalej. Chyba dobrze rozumiem? VMWare Server instalacja jest o niebo prostsza niż Xena, ale pewnie też dlatego, że VMWare Server to nie hypervisior tylko działa na chodzącym systemie. Powiedz mi, administracja takim serwerem odbywa się przez www czy tak? No ale skoro na serwerze (fizycznym) chodzi maszyna wirtualna no i jako taka tylko ona jest widoczna w sieci, to jak dostać się do panelu administracyjnego VMWare skoro w www jest serwowane przez serwer HTTP na maszynie wirtualnej?

Dopóki działa Ci mysql, to kopię zapasową możesz robić mysqldump i wtedy nie ma problemów z przywróceniem.

Żebym dobrze zrozumiał: "Dopóki działa Ci myslq" masz na myśli "dopóki przywracasz kopię na tej samej bazie, gdzie robiłeś kopię zapasową"?
a "Schody zaczynają się wtedy, jak tych baz nie ma" masz na myśli "Schody zaczynają się wtedy gdy próbujesz przywracać kopie bazy na nowym systemie z nowym mysqlem"

Czy tak?

[Pacek]

No tak, ale fizycznie mam jeden tylko serwer. Tak więc w moim przypadku (kiedy jedna maszyna zostanie zainfekowana bądź przejęta..) nie wrzucam na drugi serwer tej kopii maszyny, tylko tworzę nową instancję w ramach tego samego VMWare i jadę dalej. Chyba dobrze rozumiem? VMWare Server instalacja jest o niebo prostsza niż Xena, ale pewnie też dlatego, że VMWare Server to nie hypervisior tylko działa na chodzącym systemie. Powiedz mi, administracja takim serwerem odbywa się przez www czy tak? No ale skoro na serwerze (fizycznym) chodzi maszyna wirtualna no i jako taka tylko ona jest widoczna w sieci, to jak dostać się do panelu administracyjnego VMWare skoro w www jest serwowane przez serwer HTTP na maszynie wirtualnej?

Administracja VMWare odbywa się przez witrynę www. VMWare posiada swój własny wbudowany serwer HTTP. Nie może być tak, że ktoś ot tak Ci sie włamuje i robi z "z czterech liter jesień średniowiecza". Serwer trzeba zabezpieczyć przed atakiem zarówno z zewnątrz jak i z wewnątrz (np. przez użytkownika teoretycznie nieuprzywilejowanego). Dopóki nie zapewni się bezpieczeństwa w dostępnie do serwera to nie ma co myśleć o następnych krokach. Co z tego, że zrobisz kopię zapasową VMWare (czy innej wirtualnej maszyny) jak ktoś się dostaje na serwer i nie masz pewności, czy Twoje wirtualne maszyny są w porządku. Czy np. włamywacz ich nie skopiował i nie zrobił z nich użytku.

Żebym dobrze zrozumiał: "Dopóki działa Ci myslq" masz na myśli "dopóki przywracasz kopię na tej samej bazie, gdzie robiłeś kopię zapasową"?
A "Schody zaczynają się wtedy, jak tych baz nie ma" masz na myśli "Schody zaczynają się wtedy gdy próbujesz przywracać kopię bazy na nowym systemie z nowym mysqlem"

Dobrze, napiszę po kolei o co chodzi:
- Nie można kopiować baz danych z /var/lib/mysql podczas pracy serwera mysql. Wykonując kopię np. przez pakowanie do pliku tar trzeba ten folder wyeliminować, gdyż zwykłe kopiowanie bazy danych może spowodować rozspójnienie baz danych.
- Podczas przywrócenia z archiwum stworzonego w procesie tworzenia kopii zapasowej nie będzie baz danych z /var/lib/mysql i serwer mysql nie da się uruchomić, ponieważ nie ma bazy danych o nazwie mysql, która zawiera konfigurację, nazwy użytkowników itp.
- Z racji tego, że nie da się uruchomić serwera mysql, to nie da się przywrócić bazy danych z pliku wykonanego przez mysqldump, ponieważ do przywrócenia takiej bazy trzeba się najpierw zalogować do serwera mysql, a zgodnie z powyższym punktem on nie będzie działał
Wniosek:
Zrobić kopię bazy danych mysqlhotcopy np. do folderu /backup i dodać go do archiwizacji. Po przywróceniu serwera z archiwum należy skopiować zawartość /backup do pustego folderu /var/lib/mysql

Takie rzeczy najlepiej spróbować samemu wykonać i przetestować. Można wywodzić się na ten temat tydzień ale najlepiej sprawdzić na własnej skórze.

[Bastian]

Administracja VMWare odbywa się przez witrynę www. VMWare posiada swój własny wbudowany serwer HTTP. Nie może być tak, że ktoś ot tak Ci się włamuje i robi z "czterech liter jesień średniowiecza". Serwer trzeba zabezpieczyć przed atakiem zarówno z zewnątrz jak i z wewnątrz (np. przez użytkownika teoretycznie nieuprzywilejowanego). Dopóki nie zapewni się bezpieczeństwa w dostępnie do serwera to nie ma co myśleć o następnych krokach. Co z tego, że zrobisz kopię zapasową VMWare (czy innej wirtualnej maszyny) jak ktoś się dostaje na serwer i nie masz pewności, czy Twoje wirtualne maszyny są w porządku. Czy np. włamywacz ich nie skopiował i nie zrobił z nich użytku.

Chodziło mi o to, że posiadam serwer fizyczny. Ma on określone IP. Instaluje VMServer na nim, z minimalna ilością usług. (w zasadzie tylko ssh). Uruchamiam maszynę wirtualną i na niej instaluje wszystko co mi potrzebne. Po instalacji i konfiguracji wszystkiego, kopiuje w bezpieczne miejsce plik tej maszyny (*.img czy jak się on nazywa) jako moją kopię zapasową świeżego, skonfigurowanego systemu. Moje pytanie jest takie: jakie IP będzie miała maszyna wirtualna, żeby był do niej dostęp z zewnątrz (bo chyba nie IP maszyny fizycznej), czyli do ssh, www, ftp i wszystkich innych potrzebnych usług. I rozumiem, że jeśli dostęp do konfiguratora www, będzie po IP serwera fizycznego.

Znalazłem przystępny poradnik na temat instalacji Xena, i tam na serwerze fizycznym tworzy się właśnie maszyny wirtualne, tylko, że w przykładach był użyte adresy wewnętrzne 192.168.0.100 dla fizycznej, a wirtualne dostawały 192.168.0.101, 102, i tak dalej. Jak zatem zrobić to jeżeli fizyczna maszyna ma zewnętrzne IP i nie mamy więcej adresów do przydzielenia?

[Pacek]

Chodziło mi o to, że posiadam serwer fizyczny. Ma on określone IP. Instaluje VMServer na nim, z minimalna ilością usług. (w zasadzie tylko ssh). Uruchamiam maszynę wirtualną i na niej instaluje wszystko co mi potrzebne. Po instalacji i konfiguracji wszystkiego, kopiuje w bezpieczne miejsce plik tej maszyny (*.img czy jak się on nazywa) jako moją kopię zapasową świeżego, skonfigurowanego systemu. Moje pytanie jest takie: jakie IP będzie miała maszyna wirtualna, żeby był do niej dostęp z zewnątrz (bo chyba nie IP maszyny fizycznej), czyli do ssh, www, ftp i wszystkich innych potrzebnych usług. I rozumiem, że jeśli dostęp do konfiguratora www, będzie po IP serwera fizycznego.

Znalazłem przystępny poradnik na temat instalacji Xena, i tam na serwerze fizycznym tworzy się właśnie maszyny wirtualne, tylko, że w przykładach był użyte adresy wewnętrzne 192.168.0.100 dla fizycznej, a wirtualne dostawały 192.168.0.101, 102, i tak dalej. Jak zatem zrobić to jeżeli fizyczna maszyna ma zewnętrzne IP i nie mamy więcej adresów do przydzielenia?

Faktycznie w Twoim przypadku będzie to problematyczne ze względu na posiadany tylko jeden zewnętrzny adres IP. Trzeba by było przekierować usługi z serwera fizycznego na wirtualny np. przez iptables. Ja mam akurat tak, że posiadam DSL-a i chyba z 5 adresów do wykorzystania. Można wtedy maszynie wirtualnej nadać zewnętrzny adres IP. Jak jest tylko jeden adres IP to rodzi się z tego tytułu więcej kombinowania.