Backup całego systemu

[charles 0]

Witam

Mam serwer dedykowany w Herzner. Zastanawiam się jak można zrobić backup systemu aby w razie awarii (np. podczas uaktualniania jądra, itp. ) można było szybko przywrócić system. Mając dostęp fizyczny do maszyny nie było by problemu, ale tutaj mam tylko dostęp zdalny. Dlatego proszę i info jak można sobie poradzić z takim problemem.

 

--

charles

[beliq 442]

backup danych -> rsync

rozwiązywanie problemów z kernelem -> tryb rescue

[charles 0]

rozwiązywanie problemów z kernelem -> tryb rescue

Ok. Tylko że czasem może się trafić problem który ciężko rozwiązać. A serwer stoi. Dlatego myślałem o zrobieniu obrazu dysku który może dałoby się wysłać na serwer FTP. Czy coś takiego próbowaliście robić??

 

pozdrawiam

charles

[lukaschemp 27]

To dokup drugi dysk gdzie będziesz miał obraz całego serwer'a w tym też backup kont itd. I jak Ci coś padnie na jednym to odpalisz system z drugiego dysku. Wysyłanie obrazu systemu to by trwało za długo, to nie jest dobry pomysł.

[charles 0]

To dokup drugi dysk gdzie będziesz miał obraz całego serwer'a w tym też backup kont itd. I jak Ci coś padnie na jednym to odpalisz system z drugiego dysku. Wysyłanie obrazu systemu to by trwało za długo, to nie jest dobry pomysł.

Mam dwa dyski. Na jednym system na drugim trochę danych, czyli można by przegrać ten obraz systemu na drugi dysk. Tylko ...

1. jakim programem najlepiej to zrobić,

2. czy taki obraz trzeba robić w trybie rescue czy da się w czasie działania systemu.

[lukaschemp 27]

Robisz to za pomocą rsync'a, poszukaj informacji na ten temat, nie musisz przechodzić w żaden tryb, można to wykonać normalnie w trakcie działania systemu.

[charles 0]

Poszukam

Dzięki za pomoc.

[beliq 442]

zwykle co prawda pozwalam sobie na dość luźne pisanie na tym forum,

nie mniej jednak tym razem trzeba jedną rzecz uściślić...

jeśli kernel okaże się kolokwialnie pisząc "walnięty",

a może się to stać z najróżniejszych powodów,

nic mu nie da posiadanie kopii systemu na drugim dysku.

[lukaschemp 27]

Zgadza się, jeśli wykonuje się np. codziennie backup systemu to tak, wtedy również na drugim dysku będzie problem, lecz jeśli system jest backupowany tylko co jakiś czas, a np. codziennie same konta to wtedy nie będzie tego problemu.

[p 3]

Zgadza się, jeśli wykonuje się np. codziennie backup systemu to tak, wtedy również na drugim dysku będzie problem, lecz jeśli system jest backupowany tylko co jakiś czas, a np. codziennie same konta to wtedy nie będzie tego problemu.

Niby w jaki sposób zmniejszenie częstotliwości robienia backup'ów miałoby tutaj pomóc?

[lukaschemp 27]

W taki sposób, że gdy serwer zostanie postawiony i zoptymalizowany do działania to wtedy robimy rsync całego serwera, i wiadomo, że wszystko działa. Codziennie można wykonywać backupy kont, bo to w niczym nie przeszkadza. Oczywiście co jakiś czas można wykonać też backup całego serwera jeśli chodzi stabilnie i nie ma z nim problemów, a gdy przyjdzie "zabawa" z kernelem i coś pójdzie nie tak to wtedy po przejściu na drugi dysk system działa poprawnie prawda?

[beliq 442]

gdy przyjdzie "zabawa" z kernelem i coś pójdzie nie tak to wtedy po przejściu na drugi dysk system działa poprawnie prawda?

ehkm, niestety nie

jedyna rzecz jaka Cię może przed tym uchronić, notabene połowicznie,

to opcja fallback boot loadera grub...

jej użycie umożliwi automatycznie załadowanie poprzedniego

( w tym wypadku należy rozumieć: ostatniego sprawnego )

kernel'a po następnym reboot'ie

w innym wypadku wymagane będzie użycie trybu rescue i edycja

pliku grub.conf w celu zmiany default'owego kernel'a

[p 3]

W taki sposób, że gdy serwer zostanie postawiony i zoptymalizowany do działania to wtedy robimy rsync całego serwera, i wiadomo, że wszystko działa. Codziennie można wykonywać backupy kont, bo to w niczym nie przeszkadza. Oczywiście co jakiś czas można wykonać też backup całego serwera jeśli chodzi stabilnie i nie ma z nim problemów, a gdy przyjdzie "zabawa" z kernelem i coś pójdzie nie tak to wtedy po przejściu na drugi dysk system działa poprawnie prawda?

To w żaden sposób nie odpowiada na moje pytanie.

[zrio 6]

Z tego co sam bawię się rsyncem nie jest możliwe wykonanie kopii wszystkich plików podczas pracy systemu (oczywiście można zamontować partycje tylko do odczytu, ale wtedy / skopiujemy wyłącznie montując go z innego systemu - np. rescue). Jeśli się mylę, proszę mnie poprawić.

[beliq 442]

Z tego co sam bawię się rsyncem nie jest możliwe wykonanie kopii wszystkich plików podczas pracy systemu (oczywiście można zamontować partycje tylko do odczytu, ale wtedy / skopiujemy wyłącznie montując go z innego systemu - np. rescue). Jeśli się mylę, proszę mnie poprawić.

rfc zapewne głosi co innego, nie mniej jednak prawda jest taka,

iż bazy danych powinieneś archiwizować robiąc z nich wcześniej dump,

resztę możesz kopiować jak leci...

[zrio 6]

rfc zapewne głosi co innego, nie mniej jednak prawda jest taka,

iż bazy danych powinieneś archiwizować robiąc z nich wcześniej dump,

resztę możesz kopiować jak leci...

 

Mógłbyś rozwinąć myśl?

Montując partycje tylko do oczytu nie trzeba wykonywać dumpa dla baz, wystarczy rsync, ale "nowy" serwer musi posiadać taką samą architekturę (jeśli robimy backup / to serwer też musi być taki sam, przecież nie skopiujesz plików z serwera opartego na xeonach na PIII). Co do kopii całego systemu podczas pracy - osobiście nigdy mi się to nie udało (co Twoim zdaniem mogę robić źle) - oczywiście mówię o użyciu rsync'a.

[beliq 442]

Mógłbyś rozwinąć myśl?

Montując partycje tylko do oczytu nie trzeba wykonywać dumpa dla baz, wystarczy rsync

jasne, nie zapomnij tylko o wyłączeniu usług SQL, gdyż utracisz spójność baz

robiąc nagły remount read-only na działającym wcześniej produkcyjnie serwerze

 

"nowy" serwer musi posiadać taką samą architekturę (jeśli robimy backup / to serwer też musi być taki sam, przecież nie skopiujesz plików z serwera opartego na xeonach na PIII). Co do kopii całego systemu podczas pracy - osobiście nigdy mi się to nie udało (co Twoim zdaniem mogę robić źle) - oczywiście mówię o użyciu rsync'a.

Wszystko co napisałeś, a nawet o wiele więcej,

da się zrobić samym rsync'iem pod jednym tylko warunkiem,

że występuje zgodność architektury systemu - tj. 32 bit -> 32 bit i 64 -> 64.

To jakie dyski, kontrolery, procesory były/są nie ma znaczenia,

bo wystarczy co najwyżej zbudować monolityczny kernel ze wszystkim "jak leci",

albo dopisać odpowiednie moduły do uruchomienia wraz z systemem.

[zrio 6]

jasne, nie zapomnij tylko o wyłączeniu usług SQL, gdyż utracisz spójność baz

robiąc nagły remount read-only na działającym wcześniej produkcyjnie serwerze

To jest oczywiste

 

występuje zgodność architektury systemu - tj. 32 bit -> 32 bit i 64 -> 64.

Dokładnie to miałem na myśli