Windows Server 2012 R2 đã giảm từ 35 GB xuống còn 1,32 GB

Tôi đang thử nghiệm chống trùng lặp trên không gian lưu trữ Server 2012 R2. Tôi đã để nó chạy tối ưu hóa khấu trừ đầu tiên vào tối qua và tôi rất vui khi thấy nó yêu cầu giảm 340GB.

Tuy nhiên, tôi biết rằng điều này là quá tốt để trở thành sự thật. Trên ổ đĩa đó, 100% các khoản khấu trừ đến từ các bản sao lưu của SQL Server:

Điều đó có vẻ không thực tế, vì có những bản sao lưu cơ sở dữ liệu có kích thước gấp 20 lần trong thư mục. Ví dụ:

Nó cho rằng một tệp sao lưu 13,3 GB đã được khấu trừ thành 0 byte. Và tất nhiên, tập tin đó không thực sự hoạt động khi tôi thực hiện khôi phục thử nghiệm.

Để thêm sự xúc phạm đến thương tích, có một thư mục khác trên ổ đĩa đó có gần như một TB dữ liệu trong đó đáng lẽ đã bị mất rất nhiều, nhưng không được.

Server 2012 R2 sao chép có hoạt động không?

Chống trùng lặp không hoạt động.

Với sự trùng lặp, Kích thước trên trường đĩa trở nên vô nghĩa. Các tệp không còn là "tệp" thông thường mà là các điểm lặp lại và không chứa dữ liệu thực tế mà là siêu dữ liệu cho công cụ khấu trừ để xây dựng lại tệp. Theo hiểu biết của tôi, bạn không thể nhận được khoản tiết kiệm trên mỗi tệp vì cửa hàng chunk khấu trừ là trên mỗi khối lượng nên bạn chỉ nhận được khoản tiết kiệm trên mỗi khối lượng. http://msdn.microsoft.com/en-us/l Library / hh769303 (v = vs85) .aspx

Có lẽ công việc khấu trừ của bạn chưa hoàn thành, nếu một số dữ liệu khác chưa được khấu trừ. Nó không siêu nhanh, bị giới hạn thời gian theo mặc định và có thể bị hạn chế tài nguyên tùy thuộc vào phần cứng của bạn. Kiểm tra lịch trình khấu trừ từ Trình quản lý máy chủ.

Tôi đã triển khai khấu trừ trên một số hệ thống (Windows 2012 R2) trong các tình huống khác nhau (SCCM DP, các hệ thống triển khai khác nhau, máy chủ tệp chung, máy chủ tệp thư mục nhà người dùng, v.v.) khoảng một năm nay. Chỉ cần đảm bảo rằng bạn đã vá đầy đủ, tôi nhớ một số bản vá cho chức năng khấu trừ (cả Cập nhật tích lũy và hotfix) kể từ RTM.

Tuy nhiên, có một số vấn đề mà một số hệ thống không thể đọc dữ liệu trực tiếp từ các tệp được tối ưu hóa trong hệ thống cục bộ (IIS, SCCM trong một số trường hợp). Theo đề xuất của yagmoth555, bạn nên thử Expand-DedupFile để hủy tối đa hóa nó hoặc chỉ tạo một bản sao của tệp (tệp đích sẽ không được tối ưu hóa cho đến khi chạy tối ưu hóa tiếp theo) và thử lại. http://bloss.technet.com/b/configmgrteam/archive/2014/02/18/configuration-manager-distribution-point-and-windows-server-2012-data-ded repeatation.aspx https: //kickthatcomputer.wordpress .com / 2013/12/22 / no-input-file-spec-windows-server-2012 -recupe-on-iis-with-php /

Nếu bản sao lưu SQL của bạn thực sự bị hỏng, tôi tin rằng đó là do một vấn đề khác và không liên quan đến công nghệ sao chép.

Có vẻ như tôi có thể đã nổ súng nói rằng loại trùng lặp này là không thể. Rõ ràng, điều đó là hoàn toàn có thể, bởi vì ngoài các bản sao lưu SQL Server không nén này, tôi còn có các bản sao lưu cấp độ snapshot VMWare của máy chủ VM.

Như yagmoth555 đề xuất, tôi đã chạy một Expand-DedupeFilesố tệp 0 byte này và tôi đã nhận được một tệp hoàn toàn có thể sử dụng được ở cuối tệp.

Sau đó, tôi đã xem xét phương pháp thử nghiệm của mình để biết cách tôi xác định rằng các tệp không tốt và tôi đã tìm thấy một lỗ hổng trong các thử nghiệm của mình (quyền!).

Tôi cũng đã mở một 0-byte deduped tập tin sao lưu trong một trình soạn thảo hex, và tất cả mọi thứ có vẻ OK.

Vì vậy, tôi đã điều chỉnh phương pháp thử nghiệm của mình và mọi thứ thực sự có vẻ hiệu quả. Khi tôi rời khỏi nó, các khoản khấu trừ thực sự đã tốt hơn và giờ tôi đã tiết kiệm được hơn 1,5TB dung lượng nhờ vào khoản khấu trừ.

Tôi sẽ kiểm tra điều này kỹ lưỡng hơn trước khi đưa nó vào sản xuất, nhưng ngay bây giờ nó có vẻ đầy hứa hẹn.

Có, nhưng tôi chỉ thấy trường hợp của cụm suy luận db hypup'ed. 4tb đến 400g và VM đã chạy. Hệ điều hành đã được vá đầy đủ.

Đối với tệp sao lưu sql của bạn, nó có phải là một bãi chứa mà bạn có thể đọc trong đó không? Tôi sẽ kiểm tra nội dung. Đối với phần đó tôi không thể trả lời làm thế nào nó trích xuất tập tin ascii.