Windows Server 2012 R2 Deduped 356GB ke 1.32GB

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.

masukkan deskripsi gambar di sini

Namun, saya tahu ini terlalu bagus untuk menjadi kenyataan. Di drive itu, 100% dari dedupe berasal dari cadangan SQL Server:

masukkan deskripsi gambar di sini

Itu tampaknya tidak realistis, mengingat ada cadangan database yang berukuran 20x dalam folder. Sebagai contoh:

masukkan deskripsi gambar di sini

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?

windows-server-2012-r2 deduplication storage-spaces

— Mark Henderson
sumber

Aku harus mengingat yang itu. "Tentu saja aku tidak menghapus data kamu karena kamu membuatku kesal. Aku menguranginya menjadi 0 byte, itu saja."

— HopelessN00b

Apakah mungkin melakukan dedup dengan asumsi data relatif sama dari satu malam ke malam berikutnya. Artinya, jika Anda memiliki cadangan pertama dan terakhir, satu-satunya hal setiap malam akan menjadi snapshot dari perbedaan, seperti VSS. Secara teori, mungkin saja untuk mendeduksinya menjadi 0 mengingat salinan pertama dan terakhir mungkin cukup untuk membuat ulang file di tengah. Tapi karena gagal mengembalikan, saya akan menunggu untuk melihat apa yang Anda dapatkan sebagai penjelasan. Tetapi tes Anda tidak menjanjikan ..

— MikeAWood

@ MikeWood it de-duped backup database yang sama sekali berbeda untuk 0 byte juga, yang pasti salah. Salah satu hal yang saya inginkan dari dedupe adalah, seperti yang telah Anda tunjukkan, 90% dari cadangan dari malam ke malam adalah identik.

— Mark Henderson

@ MarkHenderson jika Anda mengatur drive baru dan menyalin semuanya, apakah itu berhasil? Hanya menebak iseng. Mungkin mirip dengan DFS di mana proses melihat data awal harus dilakukan atau akan gagal berfungsi dengan benar. Hasil Anda aneh, tidak ada pertanyaan. Semoga Anda mengetahuinya, saya ingin tahu apa yang terjadi ..

— MikeAWood

@MikeAWood - Saya tidak mencobanya. Saya telah sejak nuked drive itu dan menciptakannya kembali dengan pengaturan dedupe yang berbeda, jadi saya akan melihat apa yang terjadi malam ini ketika dump lain berjalan

— Mark Henderson

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.

— Don Zoomik
sumber

Terima kasih atas jawabannya. Jawaban Anda mencerminkan temuan saya sendiri. Saya memiliki beberapa kesalahpahaman tentang dedupe, dan metodologi pengujian saya cacat.

— Mark Henderson

@Apakah ada sesuatu tentang kesalahpahaman dan metodologi pengujian yang bisa Anda bagikan ...? Mungkin dalam posting blog? Akan menarik untuk dipelajari karena saya tidak bisa memikirkan di mana Anda (dan karena itu saya) mungkin salah. EDIT: Saya sekarang melihat jawaban Anda ... tetapi sebuah posting blog akan menjadi bacaan yang baik jika Anda memilikinya.

— Ashley

@AshleySteel Saya tidak benar-benar blog lagi. Dahulu kala. Semuanya pada dasarnya datang kepada saya tidak mengerti bagaimana Windows Server dedupe bekerja ...

— Mark Henderson

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.

— Mark Henderson
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.

— yagmoth555
sumber

Mereka adalah file biner, tetapi seperti yang telah saya sebutkan apa pun yang ada di dalamnya benar-benar rusak. Saya sebenarnya tidak memeriksa konten dalam hex editor, dan sejak itu saya nuked drive itu dan menciptakannya kembali dengan parameter dedupe yang berbeda, untuk melihat apa yang terjadi malam ini.

— Mark Henderson

@ MarkHenderson Ini bisa menjadi potongan korupsi dalam metadata dedup karena ukurannya 0. Dikutip; "Deduplikasi menimbulkan dampak korupsi satu chunk karena chunk yang populer dapat dirujuk oleh sejumlah besar file. Bayangkan chunk yang direferensikan oleh 1000 file hilang karena kesalahan sektor; Anda akan langsung mengalami kerugian 1000 file. " Cmd Perluas-DedupFile akan mengesampingkan apakah itu .bak buruk atau korupsi

— dedup