Cách GitLab giúp bạn sao lưu kho lưu trữ NextCloud lớn

Này Habr!

Hôm nay tôi muốn nói về trải nghiệm của chúng tôi trong việc tự động sao lưu dữ liệu lớn từ kho lưu trữ Nextcloud ở các cấu hình khác nhau. Tôi làm trạm dịch vụ tại Molniya AK, nơi chúng tôi quản lý cấu hình hệ thống CNTT; Nextcloud được sử dụng để lưu trữ dữ liệu. Bao gồm, với cấu trúc phân tán, có tính dự phòng.

Các vấn đề phát sinh từ các tính năng của quá trình cài đặt là có rất nhiều dữ liệu. Phiên bản do Nextcloud cung cấp, sự dư thừa, lý do chủ quan, v.v. tạo ra nhiều bản sao.

thời tiền sử

Khi quản trị Nextcloud, vấn đề tổ chức sao lưu hiệu quả phát sinh, bản sao lưu này phải được mã hóa vì dữ liệu có giá trị.

Chúng tôi cung cấp các tùy chọn để lưu trữ bản sao lưu tại địa điểm của chúng tôi hoặc tại khách hàng trên các máy riêng biệt với Nextcloud, điều này đòi hỏi cách tiếp cận quản trị tự động linh hoạt.

Có rất nhiều khách hàng, tất cả đều có cấu hình khác nhau và tất cả đều có trên trang web của riêng họ và có những đặc điểm riêng. Đây là một kỹ thuật tiêu chuẩn khi toàn bộ trang web thuộc về bạn và các bản sao lưu được tạo từ vương miện; nó không phù hợp lắm.

Đầu tiên chúng ta hãy nhìn vào dữ liệu đầu vào. Chúng tôi cần:

• Khả năng mở rộng theo một hoặc nhiều nút. Đối với các cài đặt lớn, chúng tôi sử dụng minio làm nơi lưu trữ.
• Tìm hiểu các vấn đề khi thực hiện sao lưu.
• Bạn cần giữ một bản sao lưu với khách hàng của mình và/hoặc với chúng tôi.
• Xử lý các vấn đề một cách nhanh chóng và dễ dàng.
• Khách hàng và cài đặt rất khác nhau - không thể đạt được tính đồng nhất.
• Tốc độ khôi phục phải ở mức tối thiểu trong hai trường hợp: khôi phục hoàn toàn (thảm họa), một thư mục bị xóa nhầm.
• Chức năng chống trùng lặp là cần thiết.

Để giải quyết vấn đề quản lý bản sao lưu, chúng tôi đã cài đặt GitLab. Thêm chi tiết bằng cách giải quyết.

Tất nhiên, chúng tôi không phải là người đầu tiên giải quyết vấn đề như vậy, nhưng đối với chúng tôi, có vẻ như trải nghiệm thực tế, khó khăn mới có được của chúng tôi có thể thú vị và chúng tôi sẵn sàng chia sẻ nó.

Vì công ty chúng tôi có chính sách nguồn mở nên chúng tôi đang tìm kiếm giải pháp nguồn mở. Đổi lại, chúng tôi chia sẻ những phát triển của mình và đăng chúng. Ví dụ: trên GitHub có plugin của chúng tôi dành cho Nextcloud, mà chúng tôi cung cấp cho khách hàng, tăng cường bảo mật dữ liệu trong trường hợp vô tình hoặc cố ý xóa.

Công cụ sao lưu

Chúng tôi bắt đầu tìm kiếm các phương pháp giải pháp bằng cách chọn một công cụ tạo bản sao lưu.

Tar + gzip thông thường không hoạt động tốt - dữ liệu bị trùng lặp. Một phần tăng thường chứa rất ít thay đổi thực tế và phần lớn dữ liệu trong một tệp được lặp lại.
Có một vấn đề khác - sự dư thừa của việc lưu trữ dữ liệu phân tán. Chúng tôi sử dụng minio và dữ liệu của nó về cơ bản là dư thừa. Hoặc bạn phải tạo một bản sao lưu thông qua chính minio - tải nó và sử dụng tất cả các khoảng đệm giữa hệ thống tệp, và không kém phần quan trọng, có nguy cơ quên một số nhóm và thông tin meta. Hoặc sử dụng tính năng chống trùng lặp.

Các công cụ sao lưu có tính năng sao chép có sẵn ở dạng nguồn mở (trên Habré đã có Điều về chủ đề này) và những người lọt vào vòng chung kết của chúng tôi là Borg и nghỉ ngơi. Dưới đây là so sánh của chúng tôi về hai ứng dụng, nhưng bây giờ chúng tôi sẽ cho bạn biết cách chúng tôi tổ chức toàn bộ chương trình.

Quản lý bản sao lưu

Borg và Restic đều tốt nhưng cả hai sản phẩm đều không có cơ chế kiểm soát tập trung. Với mục đích quản lý và kiểm soát, chúng tôi đã chọn một công cụ mà chúng tôi đã triển khai mà nếu không có công cụ này thì chúng tôi không thể tưởng tượng được công việc của mình, bao gồm cả tự động hóa - đây là CI/CD nổi tiếng - GitLab.

Ý tưởng như sau: gitlab-runner được cài đặt trên mỗi nút lưu trữ dữ liệu Nextcloud. Á hậu chạy một tập lệnh theo lịch để theo dõi quá trình sao lưu và khởi chạy Borg hoặc Restic.

Chúng tôi đã nhận được gì? Phản hồi từ việc thực hiện, kiểm soát thuận tiện các thay đổi, chi tiết trong trường hợp có lỗi.

Đây ở đây trên GitHub chúng tôi đã đăng các ví dụ về tập lệnh cho các tác vụ khác nhau và cuối cùng chúng tôi đã đính kèm nó vào bản sao lưu của không chỉ Nextcloud mà còn nhiều dịch vụ khác. Ngoài ra còn có một bộ lập lịch ở đó nếu bạn không muốn định cấu hình thủ công (và chúng tôi cũng không muốn) và .gitlab-ci.yml

Chưa có cách nào để thay đổi thời gian chờ CI/CD trong API Gitlab, nhưng cách này rất nhỏ. Nó cần phải được tăng lên, nói với 1d.

May mắn thay, GitLab có thể khởi chạy không chỉ theo cam kết mà chỉ theo lịch trình, đây chính xác là những gì chúng ta cần.

Bây giờ về tập lệnh bao bọc.

Chúng tôi đặt các điều kiện sau cho tập lệnh này:

• Nó phải được khởi chạy bằng cả trình chạy và bằng tay từ bảng điều khiển có cùng chức năng.
• Phải có trình xử lý lỗi:
• trả lại mã.
• tìm kiếm một chuỗi trong nhật ký. Ví dụ: đối với chúng tôi, lỗi có thể là một thông báo mà chương trình không coi là nghiêm trọng.
• Hết thời gian xử lý. Thời gian thực hiện phải hợp lý.
• Chúng tôi cần một bản ghi rất chi tiết. Nhưng chỉ trong trường hợp có lỗi.
• Một số thử nghiệm cũng được thực hiện trước khi bắt đầu.
• Phần thưởng nhỏ để thuận tiện mà chúng tôi thấy hữu ích trong quá trình hỗ trợ:
• Sự bắt đầu và kết thúc được ghi lại trong nhật ký hệ thống của máy cục bộ. Điều này giúp kết nối các lỗi hệ thống và hoạt động sao lưu.
• Một phần nhật ký lỗi, nếu có, sẽ được xuất ra thiết bị xuất chuẩn, toàn bộ nhật ký lỗi sẽ được ghi vào một tệp riêng. Sẽ rất thuận tiện khi xem xét ngay CI và đánh giá lỗi nếu nó không đáng kể.
• Các chế độ gỡ lỗi.

Nhật ký đầy đủ được lưu dưới dạng tạo phẩm trong GitLab; nếu không có lỗi, nhật ký sẽ bị xóa. Chúng tôi viết kịch bản bằng bash.

Chúng tôi sẽ sẵn lòng xem xét mọi đề xuất và nhận xét về nguồn mở - hoan nghênh.

Làm thế nào nó hoạt động

Một Á hậu với trình thực thi Bash được khởi chạy trên nút dự phòng. Theo lịch trình, công việc CI/CD được đưa ra trong một củ cải đặc biệt. Á hậu khởi chạy một tập lệnh bao bọc chung cho các tác vụ như vậy, nó kiểm tra tính hợp lệ của kho lưu trữ sao lưu, điểm gắn kết và mọi thứ chúng ta muốn, sau đó sao lưu và dọn sạch tập lệnh cũ. Bản sao lưu hoàn tất sẽ được gửi tới S3.

Chúng tôi làm việc theo sơ đồ này - đó là nhà cung cấp AWS bên ngoài hoặc nhà cung cấp tương đương của Nga (nhanh hơn và dữ liệu không rời khỏi Liên bang Nga). Hoặc chúng tôi cài đặt một cụm minio riêng cho khách hàng trên trang web của họ cho những mục đích này. Chúng tôi thường làm điều này vì lý do bảo mật khi khách hàng không muốn dữ liệu rời khỏi mạch của họ.

Chúng tôi không sử dụng tính năng gửi bản sao lưu qua ssh. Điều này không tăng thêm tính bảo mật và khả năng mạng của nhà cung cấp S3 cao hơn nhiều so với máy ssh của chúng tôi.

Để bảo vệ máy cục bộ của bạn khỏi tin tặc, vì hắn có thể xóa dữ liệu trên S3, bạn phải kích hoạt tính năng lập phiên bản.
Bản sao lưu luôn mã hóa bản sao lưu.

Borg có chế độ không được mã hóa none, nhưng chúng tôi thực sự khuyên bạn không nên bật tính năng này. Ở chế độ này, không những không có mã hóa mà tổng kiểm tra những gì đang được viết cũng không được tính toán, điều đó có nghĩa là tính toàn vẹn chỉ có thể được kiểm tra một cách gián tiếp bằng cách sử dụng các chỉ mục.

Một bộ lập lịch riêng sẽ kiểm tra các bản sao lưu về tính toàn vẹn của chỉ mục và nội dung. Việc kiểm tra diễn ra chậm và lâu nên chúng tôi tiến hành kiểm tra riêng mỗi tháng một lần. Có thể mất vài ngày.

Readme bằng tiếng Nga

Các chức năng chính

• prepare đào tạo
• testcheck kiểm tra sự sẵn sàng
• maincommand nhóm chủ lực
• forcepostscript một chức năng được thực thi cuối cùng hoặc do lỗi. Chúng tôi sử dụng nó để ngắt kết nối phân vùng.

Chức năng dịch vụ

• cleanup Chúng tôi ghi lại lỗi hoặc xóa tệp nhật ký.
• checklog phân tích nhật ký để tìm sự xuất hiện của một dòng có lỗi.
• ret xử lý thoát.
• checktimeout kiểm tra thời gian chờ.

Môi trường

• VERBOSE=1 Chúng tôi hiển thị lỗi trên màn hình ngay lập tức (stdout).
• SAVELOGSONSUCCES=1 lưu nhật ký khi thành công.
• INIT_REPO_IF_NOT_EXIST=1 Tạo một kho lưu trữ nếu nó không tồn tại. Bị tắt theo mặc định.
• TIMEOUT thời gian tối đa cho hoạt động chính. Bạn có thể đặt nó là 'm', 'h' hoặc 'd' ở cuối.

Chế độ lưu trữ các bản sao cũ. Mặc định:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Các biến bên trong tập lệnh

• ERROR_STRING — chuỗi để kiểm tra nhật ký lỗi.
• EXTRACT_ERROR_STRING — biểu thức để hiển thị chuỗi nếu có lỗi.
• KILL_TIMEOUT_SIGNAL - tín hiệu giết nếu hết thời gian.
• TAIL — có bao nhiêu chuỗi có lỗi trên màn hình.
• COLORMSG — màu của tin nhắn (màu vàng mặc định).

Đoạn script đó gọi là wordpress, có tên có điều kiện, mẹo của nó là nó còn backup cả cơ sở dữ liệu mysql. Điều này có nghĩa là nó có thể được sử dụng để cài đặt Nexcloud một nút, nơi bạn cũng có thể sao lưu cơ sở dữ liệu. Sự tiện lợi không chỉ ở chỗ mọi thứ đều ở một nơi mà nội dung của cơ sở dữ liệu cũng gần với nội dung của tệp vì sự khác biệt về thời gian là tối thiểu.

Restic vs Borg

Ngoài ra còn có sự so sánh giữa Borg và Restic ở đây trên Habré, và chúng tôi không có nhiệm vụ tạo ra một cái khác mà là của riêng chúng tôi. Điều quan trọng đối với chúng tôi là nó trông như thế nào trên dữ liệu của chúng tôi, với các chi tiết cụ thể của chúng tôi. Chúng tôi mang chúng đến.

Tiêu chí lựa chọn của chúng tôi, ngoài những tiêu chí đã được đề cập (loại bỏ trùng lặp, phục hồi nhanh, v.v.):

• Chống lại công việc còn dang dở. Kiểm tra tiêu diệt -9.
• Kích thước trên đĩa.
• Yêu cầu về tài nguyên (CPU, bộ nhớ).
• Kích thước của các đốm màu được lưu trữ.
• Làm việc với S3.
• Kiểm tra tính toàn vẹn.

Để thử nghiệm, chúng tôi đã lấy một khách hàng có dữ liệu thực và tổng kích thước là 1,6 TB.
Điều kiện.

Borg không biết cách làm việc trực tiếp với S3 và chúng tôi đã gắn đĩa làm cầu chì, thông qua ngốc nghếch. Restic đã gửi nó đến chính S3.

Goofys hoạt động rất nhanh và tốt, và có mô-đun bộ đệm đĩa, giúp tăng tốc công việc hơn nữa. Nó đang ở giai đoạn thử nghiệm và thành thật mà nói, chúng tôi đã gặp sự cố mất dữ liệu trong quá trình thử nghiệm (các thử nghiệm khác). Nhưng điều thuận tiện là bản thân quy trình sao lưu không yêu cầu đọc nhiều mà chủ yếu là ghi, vì vậy chúng tôi chỉ sử dụng bộ đệm trong quá trình kiểm tra tính toàn vẹn.

Để giảm ảnh hưởng của mạng, chúng tôi đã sử dụng nhà cung cấp địa phương - Yandex Cloud.

Kết quả thử nghiệm so sánh

• Kill -9 với lần khởi động lại tiếp theo đều thành công.
• Kích thước trên đĩa. Borg có thể nén nên kết quả đúng như mong đợi.

Sao lưu
kích thước

Borg
562Gb

nghỉ ngơi
628Gb

• Bằng CPU
  Bản thân Borg tiêu thụ rất ít, với tính năng nén mặc định, nhưng nó phải được đánh giá cùng với quy trình ngớ ngẩn. Tổng cộng, chúng tương đương nhau và sử dụng khoảng 1,2 lõi trên cùng một máy ảo thử nghiệm.
• Ký ức. Restic xấp xỉ 0,5 GB, Borg xấp xỉ 200 MB. Nhưng tất cả những điều này không đáng kể so với bộ đệm tệp hệ thống. Vì vậy, nên phân bổ nhiều bộ nhớ hơn.
• Sự khác biệt về kích thước đốm màu thật đáng kinh ngạc.

Sao lưu
kích thước

Borg
khoảng 500MB

nghỉ ngơi
khoảng 5MB

• Trải nghiệm S3 của Restic thật tuyệt vời. Làm việc với Borg thông qua goofys không đặt ra bất kỳ câu hỏi nào, nhưng cần lưu ý rằng nên thực hiện umount sau khi sao lưu hoàn tất để thiết lập lại hoàn toàn bộ đệm. Điểm đặc biệt của S3 là các khối được bơm dưới mức sẽ không bao giờ được gửi đến nhóm, điều đó có nghĩa là dữ liệu được điền không đầy đủ sẽ dẫn đến thiệt hại lớn.
• Kiểm tra tính toàn vẹn hoạt động tốt trong cả hai trường hợp, nhưng tốc độ khác nhau đáng kể.
  tĩnh lặng 3,5 giờ.
  Borg, với bộ đệm tệp SSD 100GB – 5 giờ. Kết quả tốc độ gần như tương tự nếu dữ liệu nằm trên đĩa cục bộ.
  Borg đọc trực tiếp từ S3 mà không cần bộ đệm 33 giờ. Dài khủng khiếp.

Điểm mấu chốt là Borg có thể nén và có các đốm màu lớn hơn - điều này làm cho hoạt động lưu trữ và GET/PUT trong S3 rẻ hơn. Nhưng điều này phải trả giá bằng việc xác minh phức tạp hơn và chậm hơn. Về tốc độ phục hồi, chúng tôi không nhận thấy bất kỳ sự khác biệt nào. Restic thực hiện các lần sao lưu tiếp theo (sau lần đầu tiên) lâu hơn một chút nhưng không đáng kể.

Cuối cùng nhưng không kém phần quan trọng trong sự lựa chọn là quy mô của cộng đồng.

Và chúng tôi đã chọn borg.

Một vài lời về nén

Borg có một thuật toán nén mới tuyệt vời trong kho vũ khí của mình - zstd. Chất lượng nén không tệ hơn gzip nhưng nhanh hơn nhiều. Và có thể so sánh về tốc độ với lz4 mặc định.

Ví dụ: kết xuất cơ sở dữ liệu MySQL được nén tốt hơn hai lần so với lz4 ở cùng tốc độ. Tuy nhiên, trải nghiệm với dữ liệu thực tế cho thấy có rất ít sự khác biệt về tỷ lệ nén của nút Nextcloud.

Borg có một chế độ nén khá bổ sung - nếu tệp có entropy cao thì quá trình nén hoàn toàn không được áp dụng, điều này làm tăng tốc độ. Được bật theo tùy chọn khi tạo
-C auto,zstd
cho thuật toán zstd
Vì vậy, với tùy chọn này, so với nén mặc định, chúng tôi có
lần lượt là 560Gb và 562Gb. Dữ liệu từ ví dụ trên, để tôi nhắc bạn, không nén thì kết quả là 628Gb. Kết quả chênh lệch 2GB có phần làm chúng tôi ngạc nhiên, nhưng chúng tôi nghĩ rằng rốt cuộc chúng tôi sẽ chọn nó. auto,zstd.

Phương pháp xác minh dự phòng

Theo bộ lập lịch, máy ảo được khởi chạy trực tiếp từ nhà cung cấp hoặc từ máy khách, điều này giúp giảm đáng kể tải mạng. Ít nhất thì nó cũng rẻ hơn so với việc tự mình nuôi nó và thúc đẩy lưu lượng truy cập.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

Sử dụng cùng một sơ đồ, chúng tôi kiểm tra các tệp bằng phần mềm chống vi-rút (sau khi thực tế). Suy cho cùng, người dùng tải những thứ khác nhau lên Nextcloud và không phải ai cũng có phần mềm chống vi-rút. Việc tiến hành kiểm tra tại thời điểm rót tốn quá nhiều thời gian và gây cản trở cho hoạt động kinh doanh.

Khả năng mở rộng đạt được bằng cách chạy các trình chạy trên các nút khác nhau với các thẻ khác nhau.
Quá trình giám sát của chúng tôi thu thập các trạng thái sao lưu thông qua API GitLab trong một cửa sổ; nếu cần, các vấn đề sẽ dễ dàng được nhận thấy và dễ dàng bản địa hóa.

Kết luận

Do đó, chúng tôi biết chắc chắn rằng chúng tôi tạo bản sao lưu, rằng các bản sao lưu của chúng tôi hợp lệ, các vấn đề phát sinh với chúng mất ít thời gian và được giải quyết ở cấp quản trị viên trực tiếp. Các bản sao lưu chiếm rất ít dung lượng so với tar.gz hoặc Bacula.

Nguồn: www.habr.com