Szczegóły awarii e24cloud.com (czyli o tym jak MyData.pl uratowała dane)
Duży sukces firmy MyData! Po awarii chmury firmy Beyond, pracownikom MyData (którzy w przeciwieństwie do firmy Kroll Ontrack, podjęli się próby uratowania danych) udało się w 100% odzyskać utracone dane klientów! Nic, tylko pogratulować wytrwałości i skuteczności.
Z.....3 z- #
- #
- #
- #
- #
- #
- #
- #
- #
- 81
Komentarze (81)
najlepsze
https://www.e24cloud.com/images/casestudy/image002.png
padły 2 jednostki z 5'ściu.. a potem największym problemem okazało się ustalenie kolejności dysków przypisanych do odpowiednich grup raidowych.. czy na pozostałych 3 półkach nie były przypadkiem dokładnie te same grupy raidowe (te same podziały macierzy dyskowych), a ktoś tu dał ciała wyciągając dyski bez zapisania/oznaczenia ich kolejności?
czy jest to na tyle losowa sprawa, że takie informacje i tak by nic nie dały ?
http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/RAID_6.svg/800px-RAID_6.svg.png
z tego schematu wynika, że kolejność dysków ma kluczową rolę - co się pokrywa z opisem tegoż "case study". Dalej - wnioskuję, że grupy raidowe tworzone są w jakieś fizycznej kolejności z dostępnych dysków w półce, bo skoro wszystkie dyski są identyczne, to po co by tu kombinować jakąś losowością... czyli znając kolejność dysków zamontowanych w półce, łatwo określić jest które (i
@tlucid: masz półke w której jest 24 dyski. Dla uproszczenia niech to będzie RAID 5. Kontroler dostaje dane do zapisania, więc zapisuje je np na pierwszych 3 dyskach po czym zapisuje metadane po czym kolejny zapis i kolejne dane lądują na kolejnych 3 dyskach itd. Duzy zapis zostaje rozłożony na wiele dysków bo składa się z wielu bloków danych, mały ląduje na 3 bo to pojedynczy blok. teraz czy
Ale backup ich "wewnętrzny" na rzecz fakapu? Obowiązkowy. A łączenie tych dwóch kopii (jak klient nie kupił, to w przypadku NASZEGO błędu mu nie odtworzymy) to żenada i lamerstwo.
zaufanie klientów