İş başarısı, katalog görünürlüğü, byte/hash kontrolü ve uygulamanın açılması farklı kanıtlardır. Yalnız test edilen veri, yöntem ve sürüm için sonuç çıkarın; tek bir kontrol bütün yedeklerin kurtarılabilirliğini garanti etmez.
Ekran görüntüleri 16 Ekim 2026 tarihli gerçek laboratuvar arayüzünden alınmıştır. Arayüz İngilizcedir; açıklamalar seçtiğiniz dilde sunulur. Gösterilen kaynak adları, tarihler ve ayarlar örnektir; kendi ortamınızın değerlerini kullanın.
Görsel notu: önceki gerçek laboratuvar katalog ve kurtarma noktası ekranları yeniden kullanılır. Bunlar yeni doğrulama işi veya başarılı restore kanıtı değildir. Bu içerik çalışmasında backup/restore, veri değiştirme, silme veya bütünlük taraması çalıştırılmadı.
Platform, sürüm, repository ve kurtarma noktası
Full/artımlı zinciri ve veri kapsamı
İzole hedef, kapasite ve uygulama sahibi
Ölçülebilir kabul kriteri ve kanıt kaydı
01
1. Kontrol edilecek katmanı seçin
Paket checksum’ı, backup dosyası hash’i, repository chunk doğrulaması ve uygulama tutarlılığı farklı kontrollerdir. Hangi veri ve sürümün kontrol edildiğini belirtin. SHA-256 eşleşmesi yalnız güvenilir referansla aynı byte içeriğini gösterir; tek başına kaynak kimliği veya uygulama tutarlılığı kanıtı değildir.
Beklenen sonuç
Kontrolün kanıtladığı kapsam belirlenir.
02
2. Kurtarma noktası ve bağımlılıkları belirleyin
Katalogda Full ve gereken artımlıları, parent ilişkisini, disk/dosya kapsamını ve repository kimliğini kaydedin. Eksik manifest, erişilemeyen parça veya parent hatasını görmezden gelmeyin. Katalog listesi bütün parçaların okunabildiği anlamına gelmez.
Önceki gerçek laboratuvar RESTORE seçim ekranı. Full/Incremental katalog noktalarını gösterir; okunmuş veri, hash sonucu veya eksiksiz zincir kanıtı değildir. Büyüt ↗
Beklenen sonuç
Kontrol edilecek zincir açıkça listelenir.
03
3. Güvenilir hash başlangıcını hazırlayın
Değişmeyen küçük test verisinin kaynak ve restore kopyası için aynı algoritma ve byte kapsamını kullanın. Dosya adları, boyutları ve hash sonuçlarını erişimi sınırlı kanıt kaydında tutun. Daha önce bilinmeyen bozulmuş dosyadan bugün hash üretmek geçmiş bütünlüğü kanıtlamaz.
Beklenen sonuç
Hash referansının kaynağı ve zamanı belgelenir.
04
4. Backend sözleşmesini sürümle doğrulayın
RustFS native tasarımı her object read sonrasında length ve SHA-256 doğrulaması, manifest’in en son commit edilmesi ve Full/artımlı chunk paylaşımı tarif eder. Bunlar tasarım ve sürüme bağlı kabul kapılarıdır; kurulu backend’de geçen üretim testi olarak sunulmaz. Referans verilen chunk’ı elle silmeyin veya değiştirmeyin.
Beklenen sonuç
Backend iddiası kurulu sürüm kanıtıyla eşleştirilir.
05
5. BTRFS verify sınırını ayırın
İncelenen erabackup_btrfs_dedup.py verify modu verification alanına post-dedup usage snapshot yazar; içerik hash doğrulaması veya restore yapmaz. Mount/alan raporunun başarılı olması dosyaların byte bütünlüğünü kanıtlamaz. report/verify rapor dosyası yazabilir; dedup modu extent paylaşımını değiştirir.
Beklenen sonuç
Kullanım raporu ile içerik doğrulaması ayrılır.
06
6. Uyuşmazlıkta kanıtı koruyun
Boyut/hash uyuşmazlığında iş, nokta, parça kimliği, zaman ve hata kaydını koruyun. Kaynak/restore kapsamı ile zaman tutarlılığını tekrar kontrol edin. Üretim yedeğini bozarak hata testi yapmayın; otomatik düzeltme, chunk silme veya cleanup ile kanıtı kaybetmeyin.
Beklenen sonuç
Uyuşmazlık araştırılabilir kanıtla kaydedilir.
07
7. Restore ve uygulama kontrolüyle tamamlayın
Byte kontrolünü izole restore, dosya açılışı, izinler ve uygulama/DBA kabulüyle tamamlayın. Test edilen zincir ve kapsam dışındaki veriyi raporda belirtin. Şifreleme, WORM veya başarılı hash tek başına bütün kurtarma senaryolarının kabulü değildir.
Beklenen sonuç
Bütünlük ve kurtarma kanıtı birlikte raporlanır.
MERAK EDİLENLER
BTRFS verify bütünlük taraması mıdır?
İncelenen araçta hayır. Bu mod dedup sonrası kullanım snapshot’ıdır; içerik hash’i ve geri yükleme kabulü ayrıca gerekir.