Sao lưu đám mây chậm qua VPN: tìm đúng giai đoạn

Một bản sao lưu bò qua VPN mời gọi thí nghiệm hiển nhiên: ngắt đường hầm và đo lại. Thí nghiệm đó thường trả lời một câu hỏi khác, vì tác vụ có thể đang băm tệp hoặc chờ thử lại thay vì chuyển byte. Hãy tách các giai đoạn trước, và khiếu nại trở thành một bài kiểm tra cụ thể với kết quả mong đợi cụ thể. Tuyến chỉ trở thành ứng viên khi giai đoạn truyền tải mới là thứ thực sự chậm.

Tác vụ đang ở giai đoạn nào khi có cảm giác chậm

Công cụ sao lưu đi qua các giai đoạn: phát hiện tệp, đọc và băm chúng, nén, mã hóa, tải lên rồi xác minh. Mỗi giai đoạn có nút thắt riêng, và chỉ một số giai đoạn chạm vào mạng. Một công cụ chưa báo cáo giai đoạn nào đang nói với bạn rằng nó chưa quét xong.

Tác vụ dành hai mươi phút để chuẩn bị một triệu tệp nhỏ sẽ không nhanh hơn khi đường hầm nhanh hơn. Tác vụ làm bão hòa đường truyền lên là vấn đề dung lượng với cách khắc phục khác. Đọc đầu ra tiến độ trong khi độ trễ xảy ra, ghi lại giai đoạn và thời điểm, vì giai đoạn tại thời điểm khiếu nại là giai đoạn duy nhất quan trọng. Tệp nhỏ cũng hành xử khác một đối tượng lớn, vì các lượt đi về trên mỗi tệp chiếm ưu thế và quá trình truyền không bao giờ đạt tốc độ ổn định. Hãy so sánh tương đương với tương đương trước khi kết luận về đường hầm.

Điểm cuối công khai và NAS riêng hỏng theo cách khác nhau

Dịch vụ sao lưu công khai mang theo kết nối ứng dụng đã xác thực của riêng nó, và đường hầm chỉ là một bước trên con đường dài hơn. NAS riêng thường phụ thuộc vào đường hầm đó để có thể truy cập cơ bản vào mạng của bạn. Sự khác biệt đó quyết định việc ngắt kết nối là đường cơ sở hợp lệ hay là phép thử của hư không.

Trong trường hợp công khai, cùng tác vụ qua tuyến khác có thể là so sánh công bằng khi chính sách cho phép. Trong trường hợp riêng, việc bỏ đường hầm không để lại tuyến nào tới máy chủ, nên kết quả mô tả con đường bạn đã xóa chứ không phải con đường bạn dùng.

Dừng lại là một hỏng hóc khác với truyền chậm

Cột thứ ba của bảng đó quyết định liệu có thể chạy thử nghiệm ổn định hay không, vì đường cơ sở loại bỏ đường hầm chỉ có nghĩa ở nơi tồn tại con đường khác. Với đường cơ sở dùng được, hãy xem hình dạng của hỏng hóc thay vì tốc độ trung bình. Tải lên thấp nhưng đều chỉ ra dung lượng, trong khi tác vụ dừng rồi khởi động lại chỉ ra gián đoạn, xác thực hoặc một tệp rắc rối. Hai trường hợp này tạo ra khiếu nại gần như giống nhau và cách sửa hoàn toàn khác nhau.

Các lần thử lại làm sai lệch mọi phép đo, vì số byte trên đường truyền có thể lớn hơn lượng thực sự thay đổi. Hãy đọc hành vi tiếp tục trước khi ngắt tác vụ lần nữa để xem điều gì xảy ra, vì tải lên chia phần có thể tiếp tục phục hồi rẻ còn khởi động lại toàn bộ tệp thì không. Một đường hầm kết nối lại vài phút một lần cũng trông như vấn đề băng thông khi thực ra là vấn đề ổn định. MTU đường đi làm tình hình nặng hơn, vì đường hầm giảm tải trọng hữu ích sẽ chặn các phân đoạn lớn trong khi các phân đoạn nhỏ đi qua.

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

Một lần tải lên có thể bỏ đói mọi luồng khác

Một lần tải lên lấp đầy đường truyền lên khiến cuộc gọi và duyệt web không phản hồi, và bản sao lưu hiếm khi là thứ duy nhất tranh giành nó. Một ứng dụng đồng bộ thứ hai tự nó tạo ra cùng triệu chứng. Trước khi đổ lỗi cho đường hầm, hãy xem còn gì đang tải lên.

Hãy dùng lịch hoặc giới hạn băng thông mà công cụ ghi trong tài liệu thay vì tranh giành thông lượng đỉnh; để dư chỗ cho công việc tương tác thường đáng giá hơn vài phần trăm cuối. Sau đó kiểm tra giới hạn thực sự áp lên cái gì, vì một số công cụ giới hạn theo tệp, số khác giới hạn cả lần chạy, và số khác bỏ qua hoàn toàn chi phí của tệp nhỏ. Một giới hạn không khớp với khối lượng công việc không thay đổi gì. Đường hầm chia tách cũng đáng nghi ở đây, vì loại trình khởi chạy khỏi đường hầm không loại dịch vụ hỗ trợ thực hiện việc tải lên. Rclone chẳng hạn công bố cả giới hạn truyền và hành vi thử lại trong tài liệu của mình, khiến nó thành tài liệu tham chiếu hữu ích cho việc giới hạn nên kiểm soát điều gì.

Kết thúc bằng khôi phục, không phải kiểm tra tốc độ

Một lần tải lên hoàn tất chưa phải bản sao lưu cho đến khi có thứ gì đó được khôi phục từ nó. Xác nhận rằng phiên bản mong đợi tồn tại, rồi khôi phục một tệp đại diện theo quy trình mà công cụ ghi trong tài liệu. Giữ thông tin khôi phục ở nơi khác ngoài máy hoặc hồ sơ mà bạn có thể mất, và đừng bao giờ vứt bỏ một bản sao lưu đang hoạt động chỉ để giữ thí nghiệm gọn gàng.

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

Lặp lại cả truyền tải và khôi phục sau khi thay đổi mạng, để cải thiện được chứng minh là phục vụ bản sao lưu chứ không chỉ chuyển dữ liệu nhanh hơn. Chính lần chạy thứ hai đóng phiếu. Truyền nhanh hơn với khôi phục chưa kiểm tra là cách chậm hơn để ở lại mà không có bảo vệ.