Ghi chú này thảo luận về các công cụ sao lưu thực hiện sao lưu bằng cách tạo các kho lưu trữ trên máy chủ sao lưu.
Trong số những thứ đáp ứng yêu cầu có tính trùng lặp (có giao diện đẹp ở dạng deja dup) và trùng lặp.
Một công cụ sao lưu rất đáng chú ý khác là dar, nhưng vì nó có danh sách tùy chọn rất phong phú - phương pháp thử nghiệm chỉ bao gồm 10% khả năng của nó - nên chúng tôi sẽ không thử nghiệm nó như một phần của chu trình hiện tại.
Kết quả mong đợi
Vì cả hai ứng viên đều tạo kho lưu trữ theo cách này hay cách khác nên tar thông thường có thể được sử dụng làm hướng dẫn.
Ngoài ra, chúng tôi sẽ đánh giá mức độ tối ưu hóa việc lưu trữ dữ liệu trên máy chủ lưu trữ bằng cách tạo các bản sao lưu chỉ chứa sự khác biệt giữa bản sao đầy đủ và trạng thái hiện tại của tệp hoặc giữa các bản lưu trữ trước đó và hiện tại (tăng dần, giảm dần, v.v.) .
Hành vi khi tạo bản sao lưu:
- Số lượng file trên máy chủ lưu trữ dự phòng tương đối nhỏ (có thể so sánh với số lượng bản sao lưu hoặc kích thước dữ liệu tính bằng GB) nhưng kích thước của chúng khá lớn (hàng chục đến hàng trăm megabyte).
- Kích thước kho lưu trữ sẽ chỉ bao gồm các thay đổi - sẽ không có bản sao nào được lưu trữ, do đó kích thước kho lưu trữ sẽ nhỏ hơn so với phần mềm dựa trên rsync.
- Yêu cầu 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.
Hãy chạy lệnh sau làm giá trị tham chiếu:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Kết quả thực hiện như sau:
Thời gian thực hiện 3m12s. Có thể thấy tốc độ bị giới hạn bởi hệ thống con đĩa của máy chủ lưu trữ dự phòng, như trong ví dụ với . Chỉ nhanh hơn một chút thôi, bởi vì... ghi âm đi vào một tập tin.
Ngoài ra, để đánh giá khả năng nén, hãy chạy tùy chọn tương tự nhưng bật tính năng nén ở phía máy chủ dự phòng:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Kết quả là:
Thời gian thực hiện 10m11s. Rất có thể nút cổ chai là do máy nén một dòng ở đầu nhận.
Lệnh tương tự, nhưng có tính năng nén được chuyển đến máy chủ cùng với dữ liệu gốc để kiểm tra giả thuyết rằng nút cổ chai là máy nén đơn luồng.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Hóa ra như thế này:
Thời gian thực hiện là 9m37s. Tải trọng trên một lõi của máy nén có thể nhìn thấy rõ ràng, bởi vì Tốc độ truyền mạng và tải trên hệ thống con đĩa nguồn là tương tự nhau.
Để đánh giá mã hóa, bạn có thể sử dụng openssl hoặc gpg bằng cách kết nối một lệnh bổ sung openssl hoặc gpg trong đường ống. Để tham khảo sẽ có một lệnh như thế này:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Kết quả cho ra như thế này:
Thời gian thực hiện hóa ra là 10 phút30 giây, vì 2 quy trình đang chạy ở phía nhận - nút cổ chai lại là máy nén đơn luồng, cộng với chi phí mã hóa nhỏ.
UPD: Theo yêu cầu của bliznezz, tôi đang thêm các bài kiểm tra với pigz. Nếu chỉ sử dụng máy nén thì mất 6m30s, nếu thêm mã hóa thì khoảng 7m. Phần nhúng trong biểu đồ dưới cùng là bộ đệm đĩa chưa được xóa:
Thử nghiệm trùng lặp
Bản sao là một phần mềm python để sao lưu bằng cách tạo các kho lưu trữ được mã hóa ở định dạng tar.
Đối với các kho lưu trữ gia tăng, librsync được sử dụng, do đó bạn có thể mong đợi hành vi được mô tả trong .
Các bản sao lưu có thể được mã hóa và ký bằng gnupg, điều này rất quan trọng khi sử dụng các nhà cung cấp khác nhau để lưu trữ các bản sao lưu (s3, backblaze, gdrive, v.v.)
Hãy xem kết quả là gì:
Đây là kết quả chúng tôi nhận được khi chạy không mã hóa
làm hư hỏng
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
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Và đây là kết quả khi bật mã hóa gnupg, với kích thước khóa là 2048 bit:
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
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Kích thước khối đã được chỉ định - 512 megabyte, hiển thị rõ ràng trong biểu đồ; Tải bộ xử lý thực sự vẫn ở mức 50%, có nghĩa là chương trình sử dụng không quá một lõi bộ xử lý.
Nguyên lý hoạt động của chương trình cũng được thể hiện khá rõ ràng: họ lấy một phần dữ liệu, nén lại và gửi đến máy chủ lưu trữ dự phòng, việc này có thể khá chậm.
Một tính năng khác là thời gian chạy có thể dự đoán được của chương trình, điều này chỉ phụ thuộc vào kích thước của dữ liệu đã thay đổi.
Việc kích hoạt mã hóa không làm tăng đáng kể thời gian chạy của chương trình nhưng nó làm tăng tải bộ xử lý lên khoảng 10%, đây có thể là một phần thưởng khá thú vị.
Thật không may, chương trình này không thể phát hiện chính xác tình huống đổi tên thư mục và kích thước kho lưu trữ kết quả hóa ra bằng với kích thước của các thay đổi (tức là tất cả 18GB), nhưng khả năng sử dụng máy chủ không đáng tin cậy để sao lưu rõ ràng bao trùm hành vi này.
Thử nghiệm trùng lặp
Phần mềm này được viết bằng C# và chạy bằng bộ thư viện từ Mono. Có GUI cũng như phiên bản CLI.
Danh sách gần đúng của các tính năng chính tương tự như tính năng trùng lặp, bao gồm nhiều nhà cung cấp dịch vụ lưu trữ sao lưu khác nhau, tuy nhiên, không giống như tính năng trùng lặp, hầu hết các tính năng đều khả dụng mà không cần công cụ của bên thứ ba. Đây là điểm cộng hay điểm trừ tùy thuộc vào từng trường hợp cụ thể, nhưng đối với người mới bắt đầu, rất có thể sẽ dễ dàng hơn khi có một danh sách tất cả các tính năng trước mặt chúng cùng một lúc, thay vì phải cài đặt các gói bổ sung cho python, như vậy trường hợp có sự trùng lặp.
Một sắc thái nhỏ khác - chương trình chủ động ghi cơ sở dữ liệu sqlite cục bộ thay mặt cho người dùng bắt đầu sao lưu, vì vậy bạn cần đảm bảo thêm rằng cơ sở dữ liệu cần thiết được chỉ định chính xác mỗi khi quá trình bắt đầu bằng cli. Khi làm việc thông qua GUI hoặc WEBGUI, thông tin chi tiết sẽ bị ẩn khỏi người dùng.
Hãy xem giải pháp này có thể tạo ra những chỉ số nào:
Nếu bạn tắt mã hóa (và WEBGUI không khuyến nghị thực hiện việc này) thì 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
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Khi bật mã hóa, sử dụng aes, nó 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
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Và nếu bạn sử dụng chương trình bên ngoài gnupg, kết quả sẽ xuất hiện như sau:
Khởi chạy 1
Khởi chạy 2
Khởi chạy 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Như bạn có thể thấy, chương trình có thể hoạt động trong nhiều luồng, nhưng điều này không làm cho nó trở thành một giải pháp hiệu quả hơn và nếu bạn so sánh công việc mã hóa thì nó đang khởi chạy một chương trình bên ngoài
hóa ra là nhanh hơn việc sử dụng thư viện từ bộ Mono. Điều này có thể là do chương trình bên ngoài được tối ưu hóa hơn.
Một điều thú vị khác là kích thước của kho lưu trữ chính xác bằng với dữ liệu đã thay đổi thực tế, tức là. duplicati đã phát hiện việc đổi tên thư mục và xử lý tình huống này một cách chính xác. Điều này có thể được nhìn thấy khi chạy thử nghiệm thứ hai.
Nhìn chung, ấn tượng khá tích cực về chương trình, bao gồm cả việc khá thân thiện với người mới.
Những phát hiện
Cả hai ứng cử viên đều làm việc khá chậm, nhưng nhìn chung, so với tar thông thường, có sự tiến bộ, ít nhất là với duplicati. Cái giá của sự tiến bộ đó cũng rất rõ ràng - một gánh nặng đáng chú ý
bộ xử lý. Nói chung, không có sai lệch đặc biệt nào trong việc dự đoán kết quả.
Những phát hiện
Nếu bạn không cần phải vội vã đi bất cứ đâu và cũng có bộ xử lý dự phòng, thì bất kỳ giải pháp nào được xem xét sẽ thực hiện được, trong mọi trường hợp, khá nhiều công việc đã được thực hiện mà không nên lặp lại bằng cách viết các tập lệnh bao bọc lên trên tar . Sự hiện diện của mã hóa là một thuộc tính rất cần thiết nếu máy chủ lưu trữ các bản sao lưu không thể được tin cậy hoàn toàn.
So với các giải pháp dựa trên - hiệu suất có thể kém hơn nhiều lần, mặc dù thực tế là ở dạng thuần túy tar hoạt động nhanh hơn 20-30% so với rsync.
Có sự tiết kiệm về kích thước của kho lưu trữ, nhưng chỉ với sự trùng lặp.
Thông báo
Backup Phần 3: Xem xét và kiểm tra tính trùng lặp, trùng lặp, deja dup
Backup Part 4: Review và test zbackup, restic, borgbackup
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