Wpis z mikrobloga

W sylwestra kompilowałem jądro na swoim dedyku - a że nigdy wcześniej tego nie robiłem, to rezultatu można się domyśleć.

Przez ostatnie 3 dni w trybie rescue starałem się odzyskać wszystkie dane, które tam backupowałem z innego serwera (180 GB), tak na wszelki wypadek... gdyby trzeba było robić reinstalkę.

Większym zmartwieniem była dla mnie jednak baza danych mojego Bug Trackera z danymi z ponad 2 lat (ponad 700 tasków). Starałem się jakimś cudem przywrócić backup tej bazy, który jak się okazało był.... corrupted. Okazało się, że #!$%@? był sposób jego robienia jego robienia (,).

Natomiast dzisiaj w końcu po 3 dniach udało się odzyskać to co najcenniejsze, więc cieszcie się ze mną!

Wnioski na przyszłość:
- dedyk, nawet jeżeli przy okazji dysponuje dużym dyskiem twardym (1 TB), to nie jest to jednak super miejsca na backupy z innego serwera. Rypnęło się coś innego, a ja srałem w gacie o wszystkie dane. Byłem zblokowany naprawą faktycznej przyczyny, dopóki nie zbackupowalem backupów. Nie ma to jednak jak single purpose device do backupów.
- może warto zastanowić się nad S3 i glacierem amazona
- przed powazniejszymi zmianami, warto sprawdzić, czy backupy na pewno są w stanie przywrócić Ci wszystko
- .... i tutaj najciekawsze... bo zacząłem się zastanawiać, czy nie warto by pisać unitestów do mechanizmu robienia backupów. Jakieś doświadczenia?

#oswiadczenie #sysadmin #devops troche #programowanie
  • 3
@noisy: backupy trzeba regularnie weryfikować - większość ludzi niestety uczy się tego "the hard way", podobnie jak tego, że backupy trzeba w ogóle robić :-)

S3 / Glacier jak najbardziej.

Plusik na pocieszenie ;-)
unitestów do mechanizmu robienia backupów. Jakieś doświadczenia?


@noisy: xD

wystarczy dobry admin, jeżeli brak środków na takowego to sprawdzanie tego co się robi :)