[Erp5-poland] safety

[Tomasz Brzezina]

Jacek Medrzycki pisze:
> Tomasz Brzezina pisze:
>>
>> procedura normalna:
>> 1. backupujemy skrypty ERP5 raz na dzień (żeby było szybciej niż 
>> instalowanie od zera)
> Jeśli przez "skrypty" rozumiemy zawartość INSTANCE_HOME (bez data.fs) , 
> to w zasadzie nie ma takiej potrzeby. Tam coś zmienić może jedynie 
> developer i wtedy można zrobić backup instance home.
Ok. Ok. (wyszedłem z założenia że będę tam grzebał jako developer ;D
W sensie częstych upgrejdów.

> Z drugiej strony, to co zajmuje gros miejsca to data.fs. Reszta nie jest 
> taka duża.
>> 2. backupujemy dwa razy dziennie plik data.fs
> No, powiedzmy tyle razy ile jest to wymagane przez politykę 
> bezpieczeństwa. Może wystarczać raz, może być konieczność backupowania 
> kilka razy dziennie.
> Nb., jest narzędzie (nazywa się to-to repozo.py, nie pamiętam czy jest w 
> standardzie czy musiałem doinstalować) co umożliwia robienie 
> incrementalnych i pełnych backupów data.fs bez zatrzymywania zope'a. 
> Więc jak ktoś chce, to inkrementalki można i co dziesięć minut puszczać.
O, to jest dobre, ale w kontekście problemu mysqla poniżej akceptowalne 
jest zatrzymanie zope na czas backupu.

czyli procedura backupu:
1. zatrzymanie zope
2. dump mysql'a
3. backup pliko data.fs
4. włączenie zope
4. rsync reszty dysku w tym INSTANCE_HOME (z pominięciem niektórych 
katalogów /dev, /tmp, /proc etc.

>> procedura awaryjna - w razie awarii dysku
>> 1. kupuję nowy dysk
>> 2. instaluję system, odtwarzam backup systemu
>> 3. odtwarzam drzewo ERP5 (skrypty)
>> 4. kopiuję z backupa plik data.fs
> 5a. Jeśli backup systemu nei zawierał mackupu bazy mysql, robię bazę 
> mysql, przydzielam uprawnienia i tworzę niezbędne tabele bo czasami erp5 
> sobie z tym (zrobieniem tabel) nie radzi. A czasami sobie radzi.
> Poza tym, jeśli erp5 miał jakieś nie przerobione activities, to 
> informacja o tym jest w bazie mysql tylko (IMHO). Więc dobrze dumpować 
> jest bazę myslq.
> Haczyk - jeśli erp5 ostro miele activitiesami, to prawdopodobnie backupy 
> zope-a i mysql będą out of sync. Dobrze jest robić backup Data.fs wtedy, 
> kiedy mamy pewność, że zope nie pracuje - albo faktycznie go zatrzymać, 
> mimo możliwości robienia backupu online.

>> 5. odpalam skrypt ZrobMiDobrzeIOdtworzSystem.sh
> W praktyce, jeśli był zrobiony dump bazy (albo baza nie ucierpiała) i 
> baza jest sync z Data.fs, to może nie być konieczne robienie niczego.
>> 6. czekam X minut czasu, gdzie X jest mniej niż 600
> Tu nie ma gwaracji. Reideksacja dużego sajta pewnie może trwać z godzinę.
noo 600 minut to raczej więcej niż godzina ;D

>> 7. restartuję system dla pewności
>> 8. I'm ALIVE! (brakuje mi tylko danych od ostatniego backupu)
> No w sumie się zgadza.

procedura awaryjna:
1. kupuję nowy dysk
2. instaluję system, odtwarzam backup systemu w tym instance_home
3. kopiuję z backupa plik data.fs
4. restore mysql
5. restart sytemu dla pewności
6. oczekiwanie na reindexację X minut czasu gdzie X < 600
7. UFF! Po kłopocie

-- 
T.

-------------- następna część ---------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3327 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.tiolive.com/pipermail/erp5-poland/attachments/20071126/c598c3b6/attachment.bin>