Saya bereksperimen dengan deduplikasi pada ruang penyimpanan Server 2012 R2. Saya membiarkannya menjalankan optimasi dedupe pertama tadi malam, dan saya senang melihat itu mengklaim pengurangan 340GB.
Namun, saya tahu ini terlalu bagus untuk menjadi kenyataan. Di drive itu, 100% dari dedupe berasal dari cadangan SQL Server:
Itu tampaknya tidak realistis, mengingat ada cadangan database yang berukuran 20x dalam folder. Sebagai contoh:
Ini menganggap bahwa file cadangan 13,3GB telah dikurangi menjadi 0 byte. Dan tentu saja, file itu tidak benar-benar berfungsi ketika saya melakukan tes pemulihannya.
Untuk menambah penghinaan pada cedera, ada folder lain di drive itu yang memiliki hampir TB data di dalamnya yang seharusnya banyak dikurangkan, tetapi belum.
Apakah deduplikasi Server 2012 R2 berfungsi?
sumber
Jawaban:
Deduplikasi berhasil.
Dengan deduplikasi, Ukuran pada bidang disk menjadi tidak berarti. File-file itu tidak lagi "file" biasa tetapi poin berulang dan tidak berisi data aktual tetapi metadata untuk mesin dedup untuk merekonstruksi file. Ini adalah pemahaman saya bahwa Anda tidak bisa mendapatkan penghematan per file karena simpanan chunk store adalah per volume sehingga Anda hanya mendapatkan penghematan per volume. http://msdn.microsoft.com/en-us/library/hh769303(v=vs.85).aspx
Mungkin pekerjaan dedup Anda belum selesai, jika beberapa data lain belum dipotong. Ini tidak super cepat, dibatasi waktu secara default dan mungkin terbatas sumber daya tergantung pada perangkat keras Anda. Periksa jadwal dedup dari Server Manager.
Saya telah menggunakan dedup pada beberapa sistem (Windows 2012 R2) dalam skenario yang berbeda (SCCM DP, sistem penyebaran yang berbeda, server file umum, server file folder rumah pengguna, dll) selama sekitar satu tahun sekarang. Pastikan Anda telah ditambal sepenuhnya, saya ingat beberapa tambalan untuk fungsi dedup (pembaruan kumulatif dan perbaikan terbaru) sejak RTM.
Namun ada beberapa masalah yang beberapa sistem tidak dapat membaca data langsung dari file yang dioptimalkan dalam sistem lokal (IIS, SCCM dalam beberapa skenario). Seperti yang disarankan oleh yagmoth555, Anda harus mencoba Expand-DedupFile untuk tidak mengoptimalkannya atau hanya membuat salinan file (file target akan tidak dioptimalkan sampai optimasi berikutnya berjalan) dan coba lagi. http://blogs.technet.com/b/configmgrteam/archive/2014/02/18/configuration-manager-distribution-points-and-windows-server-2012-data-deduplication.aspx https: //kickthatcomputer.wordpress .com / 2013/12/22 / no-input-file-ditentukan-windows-server-2012-dedupe-on-iis-with-php /
Jika cadangan SQL Anda benar-benar rusak, saya yakin itu karena masalah yang berbeda dan tidak terkait teknologi deduplikasi.
sumber
Sepertinya saya mungkin telah melompat pistol mengatakan bahwa deduplikasi semacam ini tidak mungkin. Rupanya, itu benar-benar mungkin, karena selain cadangan SQL Server yang tidak terkompresi ini, saya juga punya cadangan VM snapshot tingkat VMWare.
Seperti yang disarankan yagmoth555, saya menjalankan
Expand-DedupeFilebeberapa file 0-byte ini dan saya mendapatkan file yang benar-benar dapat digunakan kembali di akhir.Saya kemudian melihat metode pengujian saya untuk bagaimana saya menentukan bahwa file-file itu tidak baik, dan saya menemukan kesalahan dalam pengujian saya (izin!).
Saya juga membuka file cadangan terdeduksi 0-byte dalam hex editor, dan semuanya tampak OK.
Jadi saya menyesuaikan metodologi pengujian saya dan semuanya sepertinya berfungsi. Ketika saya meninggalkannya, dedupe sebenarnya menjadi lebih baik, dan saya sekarang telah menghemat lebih dari 1,5TB ruang berkat dedupe.
Saya akan menguji ini lebih menyeluruh sebelum saya mendorong produksi, tetapi sekarang ini terlihat menjanjikan.
sumber
Ya, tapi saya hanya melihat kasus hyperv cluster db dedup'ed. 4tb ke 400g, dan VM sedang berjalan. OS sepenuhnya ditambal.
Untuk file cadangan sql Anda, apakah ini dump yang dapat Anda baca di dalamnya? Saya akan memeriksa konten. Untuk bagian itu saya tidak bisa menjawab bagaimana itu memotong file ascii.
sumber