rsync qua VPN: bên nào là nguồn sự thật?

Hai máy chủ, một VPN, một thư mục phải tồn tại ở cả hai nơi và một lệnh dễ chạy nhưng khó hoàn tác. Trước khi gõ nó, hãy quyết định bản sao nào có thẩm quyền, vì mọi câu hỏi rsync tiếp theo đều phụ thuộc vào câu trả lời đó. Một bản sao một chiều, một thư mục làm việc chung và một kho lưu trữ có phiên bản cần những quy tắc khác nhau cho chỉnh sửa và xóa. Đường hầm cung cấp đường đi và không có ý kiến về bất kỳ điều nào trong số đó.

Quyết định bản sao nào thắng trước khi gõ lệnh

Viết hướng đi trong một câu, bao gồm tên máy chủ và đường dẫn ở mỗi bên, và được người sở hữu dữ liệu chấp thuận. Trong hướng dẫn này, nguồn là /srv/publish/ và đích là một tài khoản trên fileserver.example chỉ được phép ghi vào /srv/mirror/.

Xác nhận các dữ kiện truyền tải trước khi sao chép: khóa máy chủ SSH đã được xác minh, tài khoản đích có thể ghi vào vùng bản sao và không ghi được ở nơi khác, và cả hai máy chủ có phiên bản rsync tương thích. Những điều kiện tiên quyết này ngăn một lỗi lập kế hoạch nhỏ biến thành sự cố quyền. Chúng cũng cho bạn biết tài khoản nào sẽ xuất hiện trong nhật ký của đích khi có sự cố.

Xem trước bản sao và đọc danh sách chi tiết

Chạy bản sao trước với cờ xem trước và giữ lại kết quả. Các thay đổi chi tiết cho bạn biết điều gì sẽ xảy ra với từng đường dẫn, hữu ích hơn nhiều so với bản tóm tắt sau khi hoàn tất. Lưu kết quả vào hồ sơ thay đổi để lần chạy sau có thứ để so sánh.

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Dấu gạch chéo ở cuối rất quan trọng. Ở phía nguồn, nó có nghĩa là nội dung của thư mục đó, còn bỏ đi sẽ thêm một cấp thư mục mang tên nguồn. Hướng dẫn rsync ghi lại cả hai dạng cùng với các cờ bảo toàn siêu dữ liệu, và bộ tùy chọn bạn cần phụ thuộc vào dữ liệu chứ không phải thói quen.

Đọc từng dòng so với đích mà bạn dự định. Bỏ cờ xem trước sẽ thực hiện việc sao chép và có thể ghi đè tệp, còn nếu không có tùy chọn xóa thì các tệp thừa đã có ở đích vẫn nằm nguyên ở đó. Đây là mặc định an toàn chỉ khi bạn thực sự đã quyết định rằng các tệp cũ còn sót lại là chấp nhận được. Nếu câu trả lời là không, thì phải đưa ra quyết định xóa bên dưới, chứ không phải rắc thêm một cờ vào lệnh này.

Sau đó quyết định việc xóa có đi theo hay không

Biến đích thành gương là quyết định thứ hai, không phải sự tinh chỉnh của quyết định đầu. Hãy xem trước nó riêng, với cờ xóa được thêm vào và không thay đổi gì khác, để phần khác biệt trong danh sách hoàn toàn thuộc về quyết định đó.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Việc xóa loại bỏ các tệp thừa ở phía nhận trong phạm vi đã đồng bộ, vì vậy một đường dẫn nguồn sai, một thư mục chưa được gắn kết hoặc một bộ lọc loại trừ nhiều hơn dự định có thể khiến một lần chạy phá hoại trông giống một tấm gương sạch. Danh sách xem trước là nơi duy nhất sự khác biệt đó trở nên hữu hình trước khi trở nên tốn kém. Hãy giữ một bản sao phục hồi độc lập ở nơi dữ liệu biện minh cho điều đó, và nhớ rằng gương tái tạo trung thực một lần xóa vô ý thay vì bảo tồn lịch sử.

Xem trước cũng không khóa gì cả. Người ta chỉnh sửa tệp giữa lần thử và lần chạy thật, và hệ thống tệp có ý kiến riêng, nên lần chạy bạn phê duyệt và lần chạy thực sự diễn ra không phải cùng một thao tác trừ khi cả hai cây đều yên tĩnh.

Hai công việc một chiều không tạo ra đồng bộ hai chiều

Chạy cùng một lệnh theo cả hai hướng là cách phổ biến nhất để mất dữ liệu trong tình huống này. Mỗi hướng coi phía bên kia là đích và vui vẻ ghi đè nội dung mới hơn, còn việc xóa được phản chiếu theo thứ tự mà lịch chạy kích hoạt.

Nếu người dùng phải chỉnh sửa cả hai bản sao, đó là một quyết định sản phẩm khác: xử lý xung đột, theo dõi việc xóa và một công cụ được thiết kế cho mô hình đó. Xấp xỉ nó bằng thứ tự lịch là cách một thư mục chung có được hai phiên bản của mọi tài liệu mà không ai có thể hòa giải. Hãy quyết định rõ ràng thay vì xấp xỉ bằng hai mục cron và hy vọng.

Chỉ tự động hóa sau khi chính sách được viết ra

Một công việc theo lịch nên mang theo hướng, các đường dẫn, chính sách siêu dữ liệu và quyết định xóa đã được phê duyệt. Đặt năm dữ kiện đó trong chính tệp công việc, không phải trên một trang wiki mà người quản trị tiếp theo có thể không bao giờ đọc. Ngăn các lần chạy chồng chéo, vì hai bản sao ghi cùng một cây cùng lúc tạo ra trạng thái mà không bản nào dự định.

Khi nguồn là một cơ sở dữ liệu đang hoạt động hoặc một tập dữ liệu nhiều tệp khác, trước tiên hãy tạo bản xuất nhất quán với ứng dụng hoặc một ảnh chụp phối hợp. Việc duyệt tệp đệ quy không phải là giao dịch, và bản sao của một tập dữ liệu đang thay đổi không phải là nhất quán.

Ghi lại việc hoàn tất và thất bại, và kiểm tra tập dữ liệu ở đích thay vì chỉ mã thoát. Khôi phục VPN sau sự cố khôi phục kết nối; nó không nói gì về việc bản sao cuối cùng đã xong hay các chỉnh sửa xung đột đã bao giờ được giải quyết chưa.