Forum Debian Users Gang

Heh, tylko że jedyne co musi być pewne w tym wypadku, to to że w razie 'w' przywrócę system do pełnej sprawności. Proponujesz półśrodek, a jak wiadomo półśrodki tworzą ćwierćrezultaty, niemniej dzięki za sugestię ;)

Ja backupuje tylko dane unikalne i pliki konfiguracyjne, praktycznie tylko folder /etc.
Hołma zawsze mam na osobnej partycji, za moment na nowego dyzia pofrunie.

Postawienie Linuxa od zera jest dla mnie pewniejsze, niż ze snapshotu, w przypadku np Debiana nawet szybsze.
Gentusia zawsze mogę zainstalować od zera z gotowych paczek, które sobie siedzą w $PKGDIR.

Przy czym Gentuś jeszcze nigdy mi się tak nie wywalił, żeby przywracanie systemu było konieczne, takie rzeczy pamiętam z *buntu, ale coraz słabiej, bo *buntu wyętoliłem 5 latek temu.

Poza tym dawno nie widzialem dyzia, na którym by się nie zmieściły 3 partycje z OSami, także zawsze mam jakiś sprawny-awaryjny system pod ręką.

Do wirtualizacji polecam KVM, a do HA ucarp.

SOA#1

Przy okazji, zarówno cały geszeft małego ISP jak i sklepik całość ważnych danych trzymają w bazach SQL, więc zaprzyjaźnij się lepiej z replikacją Master => Slave albo nawet Master <=> Master (obok standardowego backupu bazy).

Pozdro

Ostatnio edytowany przez Jacekalex (2015-08-18 17:39:51)

@Jacekalex: Akurat nasz geszeft to nie tylko SQL, ale i płaskie pliki, konfiguracje, statyczne IP dla serwerów i cała masa różności które nie wpasują się ni cholery w replikację bazy :)

Pliki konfiguracyjne to się robi raz i backup do nich robi się raz.
Rdiff-backup lub Rsync tu spokojnie dają radę.

Ale już pacjentów ISP trzymasz w plikach konfiguracyjnych czy w Radiusie?
Ten Radius bardzo grzecznie bryka z bazami SQL.

Jak ktoś kupi coś w sklepiku, to masz to w bazie SQL czy w pliku?

Generalnie w  bazie SQL masz najważniejsze i często zmieniające się dane,
a w plikach konfigurację i ewentualnie obrazki, i tak to powinno działać.

Dlatego do plików z istotnymi danymi backup, bazy SQL backup + replikacja,
I najlepiej do każdej usługi publicznej zepnij dwa serwery przez UCARPA.

KVM jest sporo lżejszy od Vboxa, a oskrypcić go można tak samo.

Można też jedną VM skopiować na inny serwer, i płynnie przepiąć połączenia do niej z serwera A na serwer B.

Zależy ile tam masz gratów, i jaki obciążenie te graty muszą wytrzymać, jeśli to chodzi na Vboxie, to chyba niezbyt wiele, Vbox nigdy demonem wydajności nie był.
KVM ma jeszcze tą maluteńką przewagę, że błędami KVM zajmują się Developerzy kernela, a nie Developerzy jakiejś zewnętrznej aplikacji.

Replikację możesz wdrożyć łatwo w tej chwili, UCARPA też, ewentualna zmiana typu wirtualizacji to zabawa na inny czas, i nie obowiązkowa.
Grunt, to uporządkować cały bajzel.

Pozdro

Ostatnio edytowany przez Jacekalex (2015-08-18 18:21:16)

@lis6502 rozwiązanie typu kopia całego dysku twardego systemu operacyjnego jest raczej rzadko spotykana. Jeśli jeszcze kopia ma być aktualizowana to już będzie to ciężko ogarnąć. Podejścia są takie, że albo backupujesz dane ulotne (typu konfigi, logi, bazy danych dokumenty itp), a w razie czego na szybko stawiasz nowy system (tu nieoceniona jest wirtualizacja). Jeśli natomiast ma obywać się bez przestojów, należy zainwestować we współdzielony storage (najlepiej niezawodny typu macierz z dyskami w raidzie i kilkoma kontrolerami oraz interfejsami) oraz usługi klastrowe.

@rulezdc bacula jest bardzo dobrym rozwiązaniem, ale nie do takich zastosowań jak regularny backup całego dysku z systemem operacyjnym. Szczególnie, że jak napisał lis6502 nie może korzystać ze snapshotów, więc kopia będzie niespójna.

@Crowman, ano nie macie ;). Macie 2x 1TB, skonfigurowane jako osobne dyski skrzętnie pokrojone na partycje. A duplicity z dokumentacji brzmi nieźle, ale czy przywracanie szyfrowanej, kompresowanej kopii w okrojonym środowisku jak np sysresccd nie wymaga dodatkowych narzędzi? Trzeba też spojrzeć pod tym kątem, bo nie problemem jest skompilować nawet ze źródeł na Debianie jakiś full-featured soft, problemem jest później skrzystać z narzędzia nieobecnego w 'środowisku przywracającym'.
Ale czytając Wasze porady znalazłem wypocinki Yampress'a. Narazie testuję to w domu, na zywym organiźmie, jak się sprawdzi to chyba do tego jeszcze dokleje kopiowanie MBR i na to postawię. Tylko musi być to na 110% pewne.

Aha, dodam jeszcze że szyfrowanie i takie inne bezpiecznikowe tematy nie mają tu zastosowanie: połączenie z dyskiem sieciowym odbywa się wydzielonej sieci, a dysk nie jest widoczny jawnie ze świata.

Może zrób kopie na taśme

Przepraszam za uślizgi czasowe, jak nie zerwane światłowody to jeszcze realne życie mi się wtranca w życie xD
@mAg: budżet? Nawet nie myślałem nad kupnem czegokolwiek szczerze mówiąc. Jedynym wymiernym pieniądzem dla firmy póki co jest mój czas na to poświęcony, a że robię to że tak powiem dorywczo między serwisami typu 'nie działają internety'...
Deadline mam na poniedziałek, więc myślę przez weekend w domu przysiąść na poważnie
Serwery stawiam na vboksie, ponieważ tylko z tym mam jako takie doświadczenie wyniesione z desktopa i okazuje się że całkiem nieźle to sprawdza się na większą skalę. Zapytam tak: jesteś kolejną osobą w tym temacie która patrzy krzywo na Virtualboksa, więc prosiłbym o jakieś uzasadnienie dlaczego mój wybór był zły.
O hosta też muszę zadbać, bo chcę mieć kompleksowy pakiet backupów: pada wirtualka- wgrywam xmlki+vdi i żyje, pada host- wgrywam backupa i wracam do stanu sprzed awarii (z adresami ip, konfiguracją ssh, screena, binda &bug wie co jeszcze).
Powiem tak: downtime nie jest problemem o ile:
- kladę całą sieć (robóki na noc)
- loguje połączenia gdzieś poza VMkami (do czego dążę, bo centralizacja=zuo)
Tak, trzymam wszystko na jednym hoście (serwer SuperMicro). Dobrze że nie widziałeś tego co zastałem przed modernizacją :D
Twoja odpowiedź brzmi profesjonalnie, aż nazbyt moim zdaniem jak na naszą sieć- uważam że kupowanie jakiejś macierzy za 10k+ mija się z celem. Prędkość dzialania nie ma tu aż takiego znaczenia, niezawodność da mi kopia na dysk sieciowy (zyxel nsa 310 o ile mnie pamięć nie myli), po go generować takie koszta?
@Jacekalex: daj sobie powiedzieć że wirtualka na której mamy system zarządzania siecią sklada się w 60% z bazy i 35% z plaskich plików. 5% zajmują bugfiksy od devów xD. i to mam zabezpieczone, baza się dumpuje co noc i ląduje na FTPie zyxela, podobnie pliki- jestem w stanie w ~2h przywrócić wszystko do stanu z nocy.
Pytam jak zabezpieczyć hosta, bo o ile metodologię przywracania systemu w postaci "zainstaluj fedorę 19, pobierz łaty developerów systemu, wgraj plik licencji, wgraj i rozpakuj pliki, wgraj bazę"  mogę zrzucic na devów systemu, o tyle host którego od początku prowadzę tylko ja, ma byc do przywrócenia bez pierdzielenia się z netinstalką debiana.

Obronię zakup macierzy :] bo to też rozwiązanie Twojego problemu. Mógłbyś serwer mieć bez dysków a host mając karty HBA po FC mógłbym startować bezpośrednio z lunu na macierzy. Tam postawiłbyś system i tak miałbym wyższe HA ale rozumiem to też nie wchodzi w grę.

Tak na marginesie choć RAID byś wrzucił do host-a bo aż się prosi.

Jest jeszcze jedno rozwiązanie. Projekt FOG :] https://www.fogproject.org/

Stawiasz fog server ustalasz kiedy i z jaką częstotliwością ma się zrzucać obraz systemu na fog serv i tyle :]

Scenariusz

1. server się wyłącza 
2. bootuje po sieci 
3. zrzuca obraz po sieci 
4. restart i wstanie systemu

rozwiązanie raczej na desktopy i Twój serwer musi wspierać PXE

Ostatnio edytowany przez mAg (2015-08-20 07:17:27)

Widzę że trunkowanie VLAN'u także- chciałem podciągnąć VLAN do dysku sieciowego bezpośrednio do maszyny i roztrzasnąłem się. Czyżby w weekend szykowała się szybka migracja na KVM? xD

Jeżeli już szykujesz przesiadkę to polecam VMware Open Source nie baw się w KVM (osobiście nie mam zdania ale przy piwku przekonali mnie, że jest to półśrodek). Link do pobrania https://my.vmware.com/web/vmware/details?downloadGr … productId=491

Odnośnie zaproponowanego powyżej VMware ESXi to od siebie dodam że ilekroć mam konieczność zetknięcia z tym systemem wirtualizacji (wersja piąta) to mam wrażenie jakby coś głęboko we mnie umierało.
Osobiście nie widzę absolutnie żadnej jego przewagi nad KVM, jedynie masę problemów choćby takich jak niesamowicie okrojony hypervisor czy wybitna wybredność dotycząca sprzętu. Dodatkowo jedyne sensowne narzędzie do zarządzania takim hypervisorem to klient dostępny jedynie pod Windowsem.

No i jeżeli potrzebujesz RAID to zapomnij o softowym, odłóz z 3k zł na kontroler, uprzednio wyszukaj go jednak na liście kompatybilnych z ESXi.

Maszyna wirtualna to zbiór plików płaskich (chyba, że wystawiasz RAW Ty raczej tego nie robisz) więc piszesz skrypt który wyłączy maszynę zrzuci pliki maszyny na nas-a i włączy ją.

Chyba zdajesz sobie sprawę, że nie jest to poważne rozwiązanie (wyłączanie maszyn przy każdym backupie)? Już lepiej robić snapshot i jego backupować.

Jeśli chodzi o grubego klienta (nie webowego) - to nie wspiera on już nowych wersji HW virtualki i z czasem będzie wygaszany.

Maszynami nowego typu można zarządzać tylko przez weba. Natomiast aby odpalić konsolę webową, musisz kupić licencję na VCenter, czyli nie jest to rozwiązanie darmowe. Oczywiście możesz cały czas korzystać ze starej wersji HW dla wirtualek, ale będzie to z czasem wygaszane i nie będziesz mógł korzystać z nowych ficzerów.

Ostatnio edytowany przez jurgensen (2015-08-21 16:14:37)