Làm thế nào để sao lưu quy mô lớn Gitlab?

Khi yêu cầu Gitlab hỗ trợ về cách thực hiện sao lưu 3TB trên Gitlab tại cơ sở, họ trả lời sử dụng công cụ của chúng tôi tạo ra một tarball.

Điều này chỉ sai với tôi trên tất cả các cấp. Tarball này chứa kết xuất postgres, hình ảnh docker, dữ liệu repo, cấu hình GIT LFS, vv và vv. Sao lưu TB dữ liệu tĩnh cùng với dữ liệu rất động KB không đúng. Và sau đó là vấn đề, chúng tôi muốn sao lưu mỗi giờ.

Câu hỏi

Tôi thực sự muốn biết từ những người khác cách họ làm điều đó, để có được một bản sao lưu nhất quán.

ZFS trên Linux sẽ ổn với tôi, nếu đó là một phần của giải pháp.

— Sandra
nguồn

Tại sao điều này là sai? Bạn sao lưu hoàn toàn Gitlab của mình để khôi phục hoàn toàn. Tôi không nghĩ điều này là sai. Tất nhiên, nó sử dụng nhiều không gian hơn so với các bản sao lưu gia tăng, nhưng ... tôi không quan tâm đến kích thước sao lưu.

— Lenniey

Có một bản sao lưu mỗi giờ không phải là chưa từng thấy, nhưng không thể tạo ra 3TB trong chưa đầy một giờ với cách tiếp cận của họ. Và các bản sao lưu chỉ trong một ngày sẽ là ~ 100TB, trong đó chỉ có thể có 10 MB thay đổi đối với dữ liệu.

— Sandra

OK, đây là một câu hỏi khác, không phải về sao lưu nói chung mà là về sao lưu thường xuyên.

— Lenniey

Trong các tài liệu chính thức của họ, họ thậm chí còn đề cập đến phương pháp của họ là chậm và đề xuất các lựa chọn thay thế:

If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow. In this case you can consider using filesystem snapshots as part of your backup strategy.

mặc dù tôi không thể nói từ kinh nghiệm. Nhưng tôi có thể phải bao gồm một cái gì đó như thế này sớm ...

— Lenniey

Gitlab có các tùy chọn trong tệp cấu hình và cờ sao lưu sẽ cho phép bạn loại trừ các phần hoặc đi xa hơn để lưu trữ hình ảnh và tạo tác trên một cửa hàng đối tượng

— ssube

Câu trả lời:

Trong một khoảng thời gian ngắn như vậy giữa các lần sao lưu (1h), cách tốt nhất của bạn là dựa vào ảnh chụp nhanh và send/recv hỗ trợ ở cấp độ hệ thống tệp .

Nếu việc sử dụng ZoL không phải là vấn đề trong môi trường của bạn, tôi thực sự khuyên bạn nên sử dụng nó. ZFS là một hệ thống tập tin rất mạnh mẽ và bạn sẽ thực sự thích tất cả các tính năng bổ sung (ví dụ: nén) mà nó cung cấp. Khi được kết hợp với sanoid/syncoid, nó có thể cung cấp một chiến lược sao lưu rất mạnh. Sự không hài lòng chính là nó không được bao gồm trong kernel dòng chính, vì vậy bạn cần cài đặt / cập nhật nó một cách riêng biệt.

Ngoài ra, nếu bạn thực sự cần hạn chế những thứ có trong dòng chính, bạn có thể sử dụng BTRFS. Nhưng hãy chắc chắn để hiểu (nhiều) nhược điểm và pita của nó .

Cuối cùng, một giải pháp thay thế là sử dụng lvmthinđể sao lưu thường xuyên (ví dụ: với snapper), dựa trên các công cụ của bên thứ ba (ví dụ: bdsync, blocksync, vv) để sao chép chỉ / đồng bằng châu thổ tàu.

Một cách tiếp cận khác nhau là có hai máy nhân rộng (thông qua DRBD) trong đó bạn chụp ảnh nhanh phụ thuộc thông qua lvmthin.

— shodanshok
nguồn

Thế còn postgres? Sẽ dừng gitlab và postgres trong một phút, vì vậy một shapshot nhất quán có thể được thực hiện? Lý tưởng nhất sẽ là tuyệt vời nếu postgres có thể được đặt ở chế độ chỉ đọc trong khi ảnh chụp nhanh được thực hiện.

— Sandra

@Sandra khôi phục từ một ảnh chụp nhanh hệ thống tập tin sẽ xuất hiện với postgresql (và bất kỳ cơ sở dữ liệu được viết đúng nào khác) dưới dạng kịch bản "sự cố máy chủ" chung, kích hoạt quy trình khôi phục của chính nó (nghĩa là: cam kết với cơ sở dữ liệu chính bất kỳ trang nào được viết một phần). Nói cách khác, bạn không cần đặt postgres vào chế độ chỉ đọc khi chụp ảnh nhanh.

— shodanshok

Tôi sẽ xem lại những gì bạn đang sao lưu và có thể sử dụng phương pháp "đa đường". Ví dụ: bạn có thể sao lưu kho Git bằng cách liên tục chạy qua Git kéo trên máy chủ dự phòng. Điều đó sẽ chỉ sao chép diff và để lại cho bạn một bản sao thứ hai của tất cả các kho Git. Có lẽ bạn có thể phát hiện các repos mới bằng API.

Và sử dụng các quy trình sao lưu "tích hợp" để sao lưu các vấn đề, v.v. Tôi nghi ngờ rằng 3TB xuất phát từ phần này để bạn có thể thực hiện sao lưu rất thường xuyên với chi phí rất thấp. Bạn cũng có thể thiết lập cơ sở dữ liệu PostgreQuery với chế độ chờ ấm với bản sao.

Có thể 3TB của bạn đến từ hình ảnh container trong sổ đăng ký Docker. Bạn có cần sao lưu chúng không? Nếu vậy, có thể có một cách tiếp cận tốt hơn chỉ cho điều đó.

Về cơ bản, tôi khuyên bạn nên thực sự xem xét những gì tạo nên bản sao lưu của bạn và sao lưu dữ liệu ở nhiều phần khác nhau.

Ngay cả công cụ sao lưu từ GitLab cũng có các tùy chọn để bao gồm / loại trừ một số phần nhất định của hệ thống, chẳng hạn như Docker Registry.

— ETL
nguồn

git pull không phải là một bản sao lưu gia tăng hoàn hảo. git push --forcesẽ phá vỡ các bản sao lưu hoặc xóa lịch sử khỏi chúng, tùy thuộc vào cách nó được thực hiện.

— dùng371366

@ dn3s đó là lý do tại sao bạn luôn vô hiệu hóa git đẩy - lực lượng trên kho lưu trữ chính. Nếu ai đó muốn thay đổi lịch sử, họ có thể tự làm ngã ba và chấp nhận mọi rủi ro mà nó mang lại.

— charlie_pl

điều đó có thể tốt để sao chép , nhưng bạn không muốn tính toàn vẹn của bản sao lưu của mình dựa vào hành vi ứng dụng chính xác. Điều gì xảy ra nếu có lỗi trong ứng dụng hoặc bị định cấu hình sai? Nếu máy chủ của bạn bị xâm nhập bởi người dùng độc hại thì sao? nếu ứng dụng của bạn có khả năng xóa nội dung khỏi máy chủ sao lưu, phần lớn giá trị của các bản sao lưu từ xa gia tăng sẽ bị mất.

— dùng371366