Bu yaz\u0131, index\/journal\/dosya sistemi hiçbirinin kalmad\u0131\u011f\u0131 bir Veeam kurtarma vakas\u0131nda yazd\u0131\u011f\u0131m iki arac\u0131n teknik iç yap\u0131s\u0131n\u0131 ele al\u0131yor. Amaç hikaye anlatmak de\u011fil; kararlar\u0131n neden<\/em> öyle al\u0131nd\u0131\u011f\u0131n\u0131 ve uygulaman\u0131n nas\u0131l kuruldu\u011funu göstermek.<\/p>\n Girdi durumu:<\/p>\n \u0130ki ayr\u0131 problem s\u0131n\u0131f\u0131 var burada ve birbirine kenetli: (1) blind RAID reconstruction<\/strong> — hiçbir üst seviye metadata olmadan disk dizisinin geometrisini tespit etmek, (2) metadata's\u0131z içerik carving<\/strong> — dosya sistemi ya da backup index'i olmadan, ham bloklardan orijinal yedek yap\u0131s\u0131n\u0131 geri kurmak.<\/p>\n PC-3000 ve benzerlerinin RAID reconstruction modülleri temelde \u015funu yapar: disk ba\u015f\u0131na belirli offsetlerde dosya sistemi imzalar\u0131 arar (NTFS Bu yöntemin temel varsay\u0131m\u0131: disk üzerindeki veri deseni bozulmam\u0131\u015f<\/strong>. Benim vakamda bu varsay\u0131m geçersizdi — baz\u0131 diskler formatlan\u0131p üzerine yaz\u0131lm\u0131\u015ft\u0131, yani üzerlerindeki \"desen\" zaten farkl\u0131 bir dosya sistemi kurulumuna aitti. Algoritma orada tutarl\u0131 bir sonuç bulam\u0131yor, çünkü arad\u0131\u011f\u0131 imzalar gerçekten yok.<\/p>\n Kendi arac\u0131mda stratejiyi tersine çevirdim: dosya sistemi içeri\u011fine bak\u0131p geometriyi tahmin etmek<\/em> yerine, RAID controller'lar\u0131n disk üzerinde b\u0131rakt\u0131\u011f\u0131 kendi metadata art\u0131klar\u0131n\u0131<\/strong> do\u011frudan okumak.<\/p>\n Pratikte bu \u015fu katmanlardan olu\u015fuyor:<\/p>\n a) WWN tabanl\u0131 disk kimliklendirme<\/strong><\/p>\n Her fiziksel diskten WWN (World Wide Name) okunuyor ve bu, dizideki mant\u0131ksal disk pozisyonuyla e\u015fle\u015ftiriliyor. RAID controller'lar\u0131n ço\u011fu (LSI\/Avago, Adaptec, Intel RST) config bloklar\u0131nda disk kimliklerini saklar; bu bloklar formatla silinmemi\u015fse (genelde disk sonunda ayr\u0131 bir reserved alanda dururlar) buradan disk s\u0131ras\u0131 do\u011frudan okunabiliyor. Go taraf\u0131nda bu, b) Config art\u0131klar\u0131ndan stripe\/parity geometrisi<\/strong><\/p>\n Disklerin controller-reserved alanlar\u0131nda (genelde disk sonunda, birkaç MB'l\u0131k bir bölge) eski RAID config yap\u0131lar\u0131 kal\u0131nt\u0131 halinde duruyordu. Buradan stripe size ve parity rotasyon yönü do\u011frudan parse edildi — tahmin de\u011fil, kay\u0131t okuma. Format i\u015flemi genelde bu alanlara dokunmuyor çünkü i\u015fletim sistemi bu sektörleri \"kullan\u0131labilir alan\" olarak görmüyor.<\/p>\n c) COW katman\u0131 — sanal montaj<\/strong><\/p>\n Bu, mimarinin can al\u0131c\u0131 noktas\u0131. Elimde formatlan\u0131p üzerine yaz\u0131lm\u0131\u015f diskler oldu\u011fu için, herhangi bir yanl\u0131\u015f geometri denemesi gerçek diske yaz\u0131l\u0131rsa geri dönü\u015fü olmayan bir hasar riski var. Bu yüzden RAID'i hiçbir zaman fiziksel diske yazmadan kurdum:<\/p>\n Bunun getirdi\u011fi pratik fayda: onlarca farkl\u0131 stripe size \/ disk s\u0131ras\u0131 \/ rotasyon kombinasyonunu, her denemede gerçek diske hiç dokunmadan test edebildim. Yanl\u0131\u015f bir kombinasyon sadece \"bo\u015f\" ya da tutars\u0131z bir dosya sistemi görüntüsü veriyordu, hasar vermiyordu.<\/p>\n d) Formatlanm\u0131\u015f disklerin toparlanmas\u0131<\/strong><\/p>\n Format (özellikle h\u0131zl\u0131 format) diski s\u0131f\u0131rlamaz; yaln\u0131zca dosya sistemi metadata yap\u0131lar\u0131n\u0131 (MFT, boot sector, cluster bitmap) yeniden yazar. Kullan\u0131c\u0131 verisinin büyük k\u0131sm\u0131, yeni format taraf\u0131ndan henüz üzerine yaz\u0131lmam\u0131\u015f cluster'larda hâlâ duruyordu. Bu diskler RAID'e COW katman\u0131 üzerinden dahil edildikten sonra, RAID seviyesinde toparlanan stripe'lar zaten eski veriyi içeriyordu — çünkü format sadece dosya sistemi seviyesinde bir i\u015flemdi, RAID'in stripe düzenini de\u011fi\u015ftirmemi\u015fti.<\/p>\n RAID toparland\u0131ktan sonra elimde tutarl\u0131, okunabilir bir ham disk imaj\u0131 vard\u0131 — ama içinde ne bir dosya sistemi, ne çal\u0131\u015fan bir .vbk, ne index, ne journal.<\/p>\n Veeam backup dosyalar\u0131 (.vbk\/.vib) içeride sabit veya de\u011fi\u015fken boyutlu \"extent\" bloklar\u0131ndan olu\u015fur; her blok genelde bir header\/checksum ile ba\u015flar ve s\u0131k\u0131\u015ft\u0131rma (genelde zlib\/lz4 varyantlar\u0131) uygulanm\u0131\u015f olabilir. Format sürümüne göre detaylar de\u011fi\u015fir, ama pratikte her blo\u011fun kendi içinde bütünlük kontrolüne izin veren bir imza\/checksum alan\u0131 var. Index kaybolsa bile bu, bloklar\u0131 tek tek tan\u0131may\u0131 mümkün k\u0131l\u0131yor.<\/p>\n Araç \u015fu ak\u0131\u015fla çal\u0131\u015f\u0131yor:<\/p>\n Terabaytlarca ham veriyi taramak I\/O-bound bir i\u015f. Go taraf\u0131nda bunu \u015föyle yap\u0131land\u0131rd\u0131m:<\/p>\n \u0130ki arac\u0131n da ortak noktas\u0131 \u015fu: metadata'ya güvenmemek, ham veriden ç\u0131kan izlere güvenmek.<\/strong> RAID taraf\u0131nda bu, config art\u0131klar\u0131ndan geometri okumak ve COW ile hasars\u0131z deneme yapmak anlam\u0131na geldi. Backup taraf\u0131nda ise, blok içeri\u011finin kendi imzalar\u0131ndan bir index'i yeniden in\u015fa etmek ve eksik parçalar\u0131 çapraz yedekten kapatmak anlam\u0131na geldi.<\/p>\n Piyasadaki genel amaçl\u0131 araçlar \"temiz veri, sa\u011flam metadata\" varsay\u0131m\u0131yla optimize edilmi\u015f durumda. O varsay\u0131m çöktü\u011fünde, i\u015f orada bitmiyor — asl\u0131nda custom tooling'in gerçekten gerekli oldu\u011fu nokta oras\u0131 oluyor.<\/p>","excerpt":"Bu yaz\u0131, index\/journal\/dosya sistemi hi\u00e7birinin kalmad\u0131\u011f\u0131 bir Veeam kurtarma vakas\u0131nda yazd\u0131\u011f\u0131m iki arac\u0131n teknik i\u00e7 yap\u0131s\u0131n\u0131 ele al\u0131yor. Ama\u00e7 hikaye anlatmak de\u011fil; kararlar\u0131n neden \u00f6yle al\u0131nd\u0131\u011f\u0131n\u0131 ve uygulaman\u0131n nas\u0131l kuruldu\u011funu g\u00f6stermek.","created_at":"2026-08-04 17:10:41","updated_at":"2026-09-23 15:47:38","category_id":6,"view_count":250,"reading_time":9,"status":"published","editor_choice":0,"is_editor_choice":0,"published_at":"2026-08-04 14:10:41","featured_image":"\/uploads\/images\/2026\/08\/6a71f2cdb72b6_1785852621.jpg","slug":"kurtarilamaz-denen-raid-i-sifirdan-geri-kurmak","category_name":"Sistem","category_slug":"sistem","category_color":"#3b82f6"}Problem Tan\u0131m\u0131<\/h2>\n
\n
K\u0131s\u0131m 1: RAID Geometri Tespiti<\/h2>\n
Neden mevcut araçlar yetmedi<\/h3>\n
$MFT<\/code> kay\u0131tlar\u0131n\u0131n periyodikli\u011fi, FAT tablo tekrarlar\u0131 vb.), farkl\u0131 stripe size \/ disk s\u0131ras\u0131 \/ rotasyon kombinasyonlar\u0131n\u0131 dener, hangi kombinasyonda bu imzalar \"tutarl\u0131\" bir \u015fekilde diziliyor diye bakar. Bu, istatistiksel bir arama uzay\u0131 problemi — N disk için disk s\u0131ras\u0131 permütasyonu × olas\u0131 stripe size seti × rotasyon yönü kombinasyonlar\u0131n\u0131 taray\u0131p bir \"confidence score\" ile en iyi aday\u0131 seçiyor.<\/p>\nYakla\u015f\u0131m: Desen aramak yerine iz okumak<\/h3>\n
\/dev\/sdX<\/code> üzerinde ioctl<\/code> ile SCSI INQUIRY komutu (page 0x83) ça\u011f\u0131rarak WWN çekmek \u015feklinde uyguland\u0131 — üçüncü parti ba\u011f\u0131ml\u0131l\u0131k yok, do\u011frudan syscall seviyesinde.<\/p>\n\n
O_RDONLY<\/code>) aç\u0131l\u0131yor.<\/li>\nNBD_CMD_READ<\/code>, NBD_CMD_WRITE<\/code>, NBD_CMD_DISC<\/code>) do\u011frudan implemente ederek yap\u0131ld\u0131; harici bir ba\u011f\u0131ml\u0131l\u0131k gerekmedi.<\/li>\nnbd-client<\/code> ile bu sanal cihaz \/dev\/nbdX<\/code> olarak mount edilip üzerinde normal bir blok cihaz\u0131 gibi çal\u0131\u015f\u0131labiliyor — mdadm --assemble<\/code>, loop mount, hatta do\u011frudan dosya sistemi recovery araçlar\u0131 bu sanal cihaza kar\u015f\u0131 çal\u0131\u015ft\u0131r\u0131labiliyor.<\/li>\n<\/ul>\nK\u0131s\u0131m 2: Metadata's\u0131z Veeam Blok Carving<\/h2>\n
Veeam blok yap\u0131s\u0131na dair gözlemler<\/h3>\n
Carving stratejisi<\/h3>\n
\n
Ölçek ve gözlemlenebilirlik<\/h3>\n
\n
sync.WaitGroup<\/code> + s\u0131n\u0131rl\u0131 say\u0131da worker, disk I\/O bant geni\u015fli\u011fini bo\u011fmamak için semaphore<\/code>\/buffered channel ile s\u0131n\u0131rland\u0131).<\/li>\nsync.Map<\/code> ya da kilitli bir B-tree benzeri yap\u0131) i\u015fliyor.<\/li>\n <\/h2>\n