Bài viết này sẽ xem xét phần mềm sao lưu, bằng cách chia luồng dữ liệu thành các thành phần (khối) riêng biệt, tạo thành một kho lưu trữ.
Các thành phần kho lưu trữ có thể được nén và mã hóa thêm và quan trọng nhất - trong quá trình sao lưu lặp lại - được tái sử dụng.
Bản sao lưu trong kho lưu trữ như vậy là một chuỗi các thành phần được đặt tên được kết nối với nhau, chẳng hạn, dựa trên các hàm băm khác nhau.
Có một số giải pháp tương tự, tôi sẽ tập trung vào 3: zbackup, borgbackup và Restic.
Kết quả mong đợi
Vì tất cả những người đăng ký đều yêu cầu tạo một kho lưu trữ bằng cách này hay cách khác, một trong những yếu tố quan trọng nhất sẽ là ước tính kích thước của kho lưu trữ. Lý tưởng nhất là kích thước của nó không quá 13 GB theo phương pháp được chấp nhận hoặc thậm chí ít hơn - tùy thuộc vào sự tối ưu hóa tốt.
Người ta cũng rất mong muốn có thể tạo bản sao lưu của các tệp trực tiếp mà không cần sử dụng các trình lưu trữ như tar, cũng như hoạt động với ssh/sftp mà không cần các công cụ bổ sung như rsync và sshfs.
Hành vi khi tạo bản sao lưu:
- Kích thước của kho lưu trữ sẽ bằng kích thước của những thay đổi hoặc nhỏ hơn.
- Dự kiến sẽ có tải CPU nặng khi sử dụng tính năng nén và/hoặc mã hóa, đồng thời có thể tải mạng và ổ đĩa khá cao nếu quá trình lưu trữ và/hoặc mã hóa đang chạy trên máy chủ lưu trữ dự phòng.
- Nếu kho lưu trữ bị hỏng, lỗi chậm trễ có thể xảy ra cả khi tạo bản sao lưu mới và khi cố gắng khôi phục. Cần lập kế hoạch các biện pháp bổ sung để đảm bảo tính toàn vẹn của kho lưu trữ hoặc sử dụng các công cụ tích hợp để kiểm tra tính toàn vẹn của nó.
Làm việc với tar được lấy làm giá trị tham chiếu, như đã được trình bày trong một trong các bài viết trước.
Kiểm tra zbackup
Cơ chế chung của zbackup là chương trình tìm trong các vùng luồng dữ liệu đầu vào chứa dữ liệu giống nhau, sau đó tùy ý nén và mã hóa, mỗi vùng chỉ lưu một lần.
Tính năng chống trùng lặp sử dụng hàm băm vòng 64 bit với cửa sổ trượt để kiểm tra sự trùng khớp từng byte với các khối dữ liệu hiện có (tương tự như cách rsync triển khai nó).
Lzma và lzo đa luồng được sử dụng để nén và aes để mã hóa. Các phiên bản mới nhất có khả năng xóa dữ liệu cũ khỏi kho lưu trữ trong tương lai.
Chương trình được viết bằng C++ với sự phụ thuộc tối thiểu. Tác giả rõ ràng đã lấy cảm hứng từ unix-way, vì vậy chương trình chấp nhận dữ liệu trên stdin khi tạo bản sao lưu, tạo ra luồng dữ liệu tương tự trên stdout khi khôi phục. Do đó, zbackup có thể được sử dụng như một “khối xây dựng” rất tốt khi viết các giải pháp sao lưu của riêng bạn. Ví dụ, tác giả bài viết đã sử dụng chương trình này làm công cụ sao lưu chính cho máy gia đình từ khoảng năm 2014.
Luồng dữ liệu sẽ là tar thông thường trừ khi có quy định khác.
Hãy xem kết quả là gì:
Tác phẩm đã được kiểm tra theo 2 lựa chọn:
- một kho lưu trữ được tạo và zbackup được khởi chạy trên máy chủ cùng với dữ liệu nguồn, sau đó nội dung của kho lưu trữ sẽ được chuyển đến máy chủ lưu trữ dự phòng.
- một kho lưu trữ được tạo trên máy chủ lưu trữ dự phòng, zbackup được khởi chạy qua ssh trên máy chủ lưu trữ dự phòng và dữ liệu được gửi đến nó qua đường ống.
Kết quả của tùy chọn đầu tiên như sau: 43m11s - khi sử dụng kho lưu trữ không được mã hóa và máy nén lzma, 19m13s - khi thay thế máy nén bằng lzo.
Tải trên máy chủ với dữ liệu gốc như sau (một ví dụ với lzma được hiển thị; với lzo có hình ảnh gần giống nhau, nhưng tỷ lệ rsync là khoảng một phần tư thời gian):
Rõ ràng là quy trình sao lưu như vậy chỉ phù hợp với những thay đổi nhỏ và tương đối hiếm. Bạn cũng nên giới hạn zbackup ở 1 luồng, nếu không sẽ có tải CPU rất cao, bởi vì Chương trình này hoạt động rất tốt trong nhiều chủ đề. Tải trên đĩa nhỏ, nhìn chung sẽ không đáng chú ý với hệ thống con đĩa dựa trên ssd hiện đại. Bạn cũng có thể thấy rõ sự bắt đầu của quá trình đồng bộ hóa dữ liệu kho lưu trữ với máy chủ từ xa; tốc độ hoạt động tương đương với rsync thông thường và phụ thuộc vào hiệu suất của hệ thống con đĩa của máy chủ lưu trữ dự phòng. Nhược điểm của phương pháp này là việc lưu trữ một kho lưu trữ cục bộ và do đó, dữ liệu bị trùng lặp.
Thú vị hơn và có thể áp dụng trong thực tế là tùy chọn thứ hai, chạy zbackup trực tiếp trên máy chủ lưu trữ dự phòng.
Đầu tiên, chúng tôi sẽ kiểm tra hoạt động mà không sử dụng mã hóa với máy nén lzma:
Thời gian chạy của mỗi lần chạy thử nghiệm:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Nếu bạn kích hoạt mã hóa bằng aes, kết quả khá gần:
Thời gian hoạt động trên cùng một dữ liệu, có mã hóa:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Nếu mã hóa được kết hợp với nén bằng lzo, nó sẽ trông như thế này:
giờ làm việc:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Kích thước của kho lưu trữ kết quả tương đối giống nhau ở mức 13 GB. Điều này có nghĩa là tính năng chống trùng lặp đang hoạt động chính xác. Ngoài ra, trên dữ liệu đã được nén, sử dụng lzo mang lại hiệu quả rõ rệt; xét về tổng thời gian hoạt động, zbackup gần bằng tính trùng lặp/trùng lặp, nhưng tụt hậu so với dữ liệu dựa trên librsync từ 2-5 lần.
Ưu điểm là rõ ràng - tiết kiệm dung lượng ổ đĩa trên máy chủ lưu trữ dự phòng. Đối với các công cụ kiểm tra kho lưu trữ, tác giả của zbackup không cung cấp chúng, nên sử dụng mảng đĩa hoặc nhà cung cấp đám mây có khả năng chịu lỗi.
Nhìn chung, một ấn tượng rất tốt, mặc dù thực tế là dự án đã đứng yên khoảng 3 năm (yêu cầu tính năng cuối cùng là khoảng một năm trước nhưng không có phản hồi).
Kiểm tra borgbackup
Borgbackup là một nhánh của gác mái, một hệ thống khác tương tự như zbackup. Được viết bằng python, nó có một danh sách các khả năng tương tự như zbackup, nhưng ngoài ra còn có thể:
- Gắn bản sao lưu qua cầu chì
- Kiểm tra nội dung kho lưu trữ
- Làm việc ở chế độ client-server
- Sử dụng nhiều loại máy nén khác nhau cho dữ liệu cũng như xác định loại tệp theo kinh nghiệm khi nén nó.
- 2 tùy chọn mã hóa, aes và blake
- Công cụ tích hợp cho
kiểm tra hiệu suất
điểm chuẩn borgbackup crud ssh://backup_server/repo/path local_dir
Kết quả như sau:
C-Z-BIG 96.51 MB/s (10 100.00 MB tệp hoàn toàn bằng 10.36: XNUMX giây)
R-Z-BIG 57.22 MB/s (10 100.00 MB tệp hoàn toàn bằng 17.48: XNUMX giây)
U-Z-BIG 253.63 MB/s (10 100.00 MB tệp hoàn toàn bằng 3.94: XNUMX giây)
D-Z-BIG 351.06 MB/s (10 100.00 MB tệp hoàn toàn bằng 2.85: XNUMX giây)
C-R-BIG 34.30 MB/s (10 Tệp ngẫu nhiên 100.00 MB: 29.15 giây)
R-R-BIG 60.69 MB/s (10 Tệp ngẫu nhiên 100.00 MB: 16.48 giây)
U-R-BIG 311.06 MB/s (10 Tệp ngẫu nhiên 100.00 MB: 3.21 giây)
D-R-BIG 72.63 MB/s (10 Tệp ngẫu nhiên 100.00 MB: 13.77 giây)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB tệp hoàn toàn bằng 9.21: XNUMX giây)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB tệp hoàn toàn bằng 13.13: XNUMX giây)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB tệp hoàn toàn bằng 3.02: XNUMX giây)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB tệp hoàn toàn bằng 2.58: XNUMX giây)
C-R-MEDIUM 37.80 MB/s (1000 Tệp ngẫu nhiên 1.00 MB: 26.45 giây)
R-R-MEDIUM 68.90 MB/s (1000 Tệp ngẫu nhiên 1.00 MB: 14.51 giây)
U-R-MEDIUM 347.24 MB/s (1000 Tệp ngẫu nhiên 1.00 MB: 2.88 giây)
DR-MEDIUM 48.80 MB/s (1000 Tệp ngẫu nhiên 1.00 MB: 20.49 giây)
C-Z-NHỎ 11.72 MB/giây (10000 10.00 kB tệp hoàn toàn bằng 8.53: XNUMX giây)
R-Z-NHỎ 32.57 MB/giây (10000 10.00 kB tệp hoàn toàn bằng 3.07: XNUMX giây)
U-Z-NHỎ 19.37 MB/giây (10000 10.00 kB tệp hoàn toàn bằng 5.16: XNUMX giây)
D-Z-NHỎ 33.71 MB/giây (10000 10.00 kB tệp hoàn toàn bằng 2.97: XNUMX giây)
C-R-NHỎ 6.85 MB/giây (10000 Tệp ngẫu nhiên 10.00 kB: 14.60 giây)
R-R-NHỎ 31.27 MB/giây (10000 Tệp ngẫu nhiên 10.00 kB: 3.20 giây)
U-R-NHỎ 12.28 MB/giây (10000 Tệp ngẫu nhiên 10.00 kB: 8.14 giây)
DR-NHỎ 18.78 MB/giây (10000 Tệp ngẫu nhiên 10.00 kB: 5.32 giây)
Khi kiểm tra, heuristic nén sẽ được sử dụng để xác định loại file (tự động nén) và kết quả sẽ như sau:
Trước tiên, hãy kiểm tra xem nó hoạt động như thế nào mà không cần mã hóa:
giờ làm việc:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Nếu bạn bật ủy quyền kho lưu trữ (chế độ xác thực), kết quả sẽ đóng:
giờ làm việc:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Khi mã hóa aes được kích hoạt, kết quả không xấu đi nhiều:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Và nếu bạn đổi aes thành blake thì tình hình sẽ được cải thiện hoàn toàn:
giờ làm việc:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Như trong trường hợp của zbackup, kích thước kho lưu trữ là 13 GB và thậm chí ít hơn một chút, điều này thường được mong đợi. Tôi rất hài lòng với thời gian chạy; nó có thể so sánh với các giải pháp dựa trên librsync, cung cấp khả năng rộng hơn nhiều. Tôi cũng hài lòng với khả năng thiết lập các tham số khác nhau thông qua các biến môi trường, điều này mang lại lợi thế rất lớn khi sử dụng borgbackup ở chế độ tự động. Tôi cũng hài lòng với tải trong quá trình sao lưu: xét theo tải của bộ xử lý, borgbackup hoạt động trong 1 luồng.
Không có nhược điểm cụ thể khi sử dụng nó.
thử nghiệm tĩnh
Mặc dù thực tế rằng Restistic là một giải pháp khá mới (2 ứng cử viên đầu tiên đã được biết đến từ năm 2013 trở về trước), nhưng nó có những đặc điểm khá tốt. Viết bằng Go.
Khi so sánh với zbackup, nó còn mang lại:
- Kiểm tra tính toàn vẹn của kho lưu trữ (bao gồm kiểm tra từng phần).
- Một danh sách khổng lồ các giao thức và nhà cung cấp được hỗ trợ để lưu trữ các bản sao lưu cũng như hỗ trợ rclone - rsync cho các giải pháp đám mây.
- So sánh 2 bản sao lưu với nhau.
- Gắn kho lưu trữ thông qua Fuse.
Nhìn chung, danh sách các tính năng khá gần với borgbackup, ở một số nơi nhiều hơn, ở những nơi khác ít hơn. Một trong những tính năng là không có cách nào để vô hiệu hóa mã hóa và do đó các bản sao lưu sẽ luôn được mã hóa. Hãy xem trong thực tế những gì có thể được khai thác từ phần mềm này:
Kết quả như sau:
giờ làm việc:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Kết quả hiệu suất cũng tương đương với các giải pháp dựa trên rsync và nói chung là rất gần với borgbackup, nhưng tải CPU cao hơn (chạy nhiều luồng) và răng cưa.
Rất có thể, chương trình bị giới hạn bởi hiệu suất của hệ thống con đĩa trên máy chủ lưu trữ dữ liệu, như trường hợp của rsync. Kích thước kho lưu trữ là 13GB, giống như zbackup hoặc borgbackup, không có nhược điểm rõ ràng nào khi sử dụng giải pháp này.
Những phát hiện
Trên thực tế, tất cả các ứng viên đều đạt được kết quả tương tự nhưng ở mức giá khác nhau. Borgbackup hoạt động tốt nhất, Restic chậm hơn một chút, zbackup có lẽ không đáng để bắt đầu sử dụng,
và nếu nó đã được sử dụng, hãy thử thay đổi nó thành borgbackup hoặc Restic.
Những phát hiện
Giải pháp hứa hẹn nhất có vẻ là ổn định, bởi vì... chính anh ta là người có tỷ lệ khả năng và tốc độ vận hành tốt nhất, nhưng bây giờ chúng ta đừng vội đưa ra kết luận chung.
Borgbackup về cơ bản không tệ hơn, nhưng zbackup có lẽ được thay thế tốt hơn. Đúng, zbackup vẫn có thể được sử dụng để đảm bảo quy tắc 3-2-1 hoạt động. Ví dụ: ngoài các phương tiện sao lưu dựa trên (lib)rsync.
Thông báo
Backup Phần 5: Test bacula và veeam backup cho linux
Sao lưu Phần 6: So sánh các công cụ sao lưu
Sao lưu Phần 7: Kết luận
Gửi bởi: Pavel Demkovich
Nguồn: www.habr.com