rsync tiếp tục ngắt kết nối: đường ống bị hỏng

Tôi đang sử dụng rsyncđể sao lưu thư mục nhà của tôi. Điều này đã làm việc tốt trong một thời gian dài bây giờ. Đây là lệnh tôi đang sử dụng:

rsync \
    -pavz \
    --delete \
    --exclude 'mnt/' \
    --exclude '.cache/' \
    --exclude 'Videos/' \
    --exclude 'Music/' \
    --exclude 'Documents/virtualbox' \
    /home/"${USER}" "${server}":"${dir}" 2>> "${errorFile}"

Tuy nhiên, tôi đã chuyển máy chủ mà tôi đang sao lưu và bây giờ rsynckhởi động và chạy trong vài giây (tối đa vài phút), nhưng sau đó dừng lại với thông báo lỗi

packet_write_wait: Connection to x.x.x.x: Broken pipe
rsync: [sender] write error: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.1]

Vì nó đang hoạt động trên các máy chủ khác, tôi nghi ngờ rằng vấn đề là do kết nối hoặc chính máy chủ. Kết nối dường như ổn định. Tôi được kết nối qua cáp và tôi không thấy bất kỳ sự gián đoạn nào. Tôi cũng đã thử ping máy chủ trong khi thực hiện sao lưu. Ping có tỷ lệ phản hồi 100% ngay cả khi sao lưu bị phá vỡ.

Tôi sử dụng kerberosđể xác thực trên máy chủ từ xa.

Tôi đã thử một vài kết hợp với ServerAliveInterval, ServerAliveCountMaxhoặc ClientAliveIntervaltrong tôi ~/.ssh/config, nhưng không có kết quả.

Có thể có một cái gì đó đang chạy trên máy chủ giết chết rsynclệnh vì một số lý do, nhưng tôi không biết làm thế nào để điều tra trong đó. Có ý kiến ​​gì không?

Vấn đề của bạn có thể là (thiếu) bộ nhớ. Quay lại khi 1GB là lớn đối với một máy chủ, rsync sẽ thất bại đối với tôi đối với các bộ dữ liệu lớn. Có lẽ thuật toán đã cải thiện dung lượng bộ nhớ đã tăng lên, nhưng tôi đã không thấy vấn đề đó trong 8 năm hoặc lâu hơn. Vì vậy, thực sự, đây là một shot bên ngoài, nhưng đáng để khám phá. Hãy thử bộ dữ liệu nhỏ hơn trước. Bạn cũng có thể thử - như một hình thức kiểm tra độ tỉnh táo - thực hiện tar-tar:

tar cf - $HOME | ssh ${server} tar xf -

Nếu điều đó cũng thất bại sau vài phút, đó không phải là bộ nhớ.

Tôi đã gặp điều này với rsynctrong quá khứ là tốt. Giải pháp khắc phục nó cho tôi là chạy nó từ trong một screenphiên, có thể giúp duy trì kết nối đến máy chủ từ xa.

screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session

Bạn có thể kiểm tra trạng thái bằng cách chạy screen -x rsync(hoặc bất cứ điều gì bạn quyết định đặt tên phiên nếu bạn đặt tên cho nó, không bắt buộc). Điều này sẽ gắn lại shell hiện tại của bạn vào phiên đó. Chỉ cần nhớ tách ra một lần nữa sau khi bạn đã kiểm tra trạng thái để nó tiếp tục chạy trong nền.

Bạn cũng có thể thực thi lệnh để chạy screentrong nền trong một lần trượt thất bại bằng cách thực hiện [ai đó vui lòng sửa cho tôi nếu tôi sai] screen -dm 'command'. Bạn có thể muốn man screentrước khi thử cái cuối cùng.

BIÊN TẬP:

Tôi đang chỉnh sửa câu trả lời của mình vì bạn đã xác nhận rằng screenkhông cung cấp hỗ trợ nào trong kịch bản này, nhưng bạn đã trả lời nhận xét của tôi đề nghị thử scpxem loại kết quả nào bạn nhận được, mà bạn đã trả lời đủ kỳ lạ, nó hoạt động tốt.

Vì vậy, câu trả lời mới của tôi là: sử dụng scp- hoặc ssh(với tar) - thay vìrsync

Cấp, scpkhông hỗ trợ số lượng lớn các tính năng như rsync, nhưng bạn thực sự sẽ ngạc nhiên để khám phá chỉ có bao nhiêu tính năng mà nó không hỗ trợ mà gần như giống hệt như của rsync.

Kịch bản thế giới thực cho scpvà các lựa chọn thay thế khác cho rsync:

Trước đó, tôi được giao nhiệm vụ tạo một tập lệnh shell sẽ lấy các bản ghi từ các máy chủ sản xuất của chúng tôi và lưu trữ chúng cục bộ trên một máy chủ web để các nhà phát triển có thể truy cập chúng cho mục đích khắc phục sự cố. Sau khi thử không thành công để nhóm Unix cài đặt rsynctrên máy chủ của chúng tôi, tôi đã tìm ra cách giải quyết bằng cách sử dụng scpnó cũng hoạt động tốt.

Điều đó đang được nói, gần đây tôi đã sửa đổi tập lệnh để tất cả những gì nó sử dụng là sshvà tar- GNU tar/ gtar, chính xác. GNU tarhỗ trợ nhiều tùy chọn mà bạn thực sự sẽ tìm thấy rsync, chẳng hạn như --include, --excludebảo toàn quyền / thuộc tính, nén, v.v.

Cách bây giờ tôi thực hiện điều này là bằng cách gửi sshđến máy chủ từ xa (thông qua pubkey auth) và sử dụng gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]- điều này ghi tất cả thông tin stdout, sau đó được dẫn [cục bộ] để tar -xzfkhông có thay đổi nào được thực hiện trên máy chủ sản xuất từ ​​xa và tất cả các tệp đã được chuyển đến máy chủ cục bộ. Đó là một sự thay thế tuyệt vời rsynctrong trường hợp này. Điều quan trọng duy nhất không hỗ trợ tarcũng không phải scplà sao lưu gia tăng và mức độ kiểm tra lỗi ở cấp độ khối rsync.

Lệnh đầy đủ mà tôi đang đề cập khi sử dụng sshvà tarsẽ là một cái gì đó như thế này (từ xa là Solaris 10; cục bộ là Debian, với giá trị của nó):

cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz

Trong kịch bản của bạn, nó sẽ ngược lại - tar -cf -cục bộ và chuyển sang máy chủ từ xa thông qua ssh user@remotehost "tar -xf -"- có một câu trả lời khác tham chiếu loại hành vi này nhưng không đi sâu vào chi tiết.

Có một vài lựa chọn khác mà tôi đã đưa vào để tăng tốc mọi thứ. Tôi hẹn giờ mọi thứ không ngừng nghỉ để có được thời gian thực hiện càng thấp càng tốt. Bạn sẽ nghĩ rằng sử dụng nén với tarsẽ là vô nghĩa, nhưng nó thực sự tăng tốc mọi thứ lên một chút, cũng như sử dụng -Ccờ với sshđể cho phép sshnén. Tôi có thể cập nhật bài đăng này vào một ngày sau đó để bao gồm lệnh chính xác mà tôi sử dụng (rất giống với những gì tôi đã đăng), nhưng tôi không cảm thấy muốn truy cập VPN vào lúc này kể từ khi tôi đi nghỉ tuần này.

Trên Solaris 10, tôi cũng sử dụng -c blowfish, vì đây là mật mã nhanh nhất để xác thực và cũng giúp tăng tốc mọi thứ, nhưng Solaris 11 của chúng tôi không hỗ trợ hoặc tắt bộ mật mã này.

Ngoài ra, nếu bạn chọn sử dụng tùy chọn ssh/ tar, thực sự sẽ là một ý tưởng tốt để triển khai giải pháp sử dụng ban đầu của tôi screennếu bạn đang thực hiện sao lưu sẽ mất một lúc. Nếu không, hãy đảm bảo các cài đặt giữ lại / hết thời gian trong bạn ssh_configđược điều chỉnh vừa phải, hoặc phương pháp này cũng sẽ rất có thể gây ra vỡ đường ống.

Ngay cả khi bạn đi cùng scp, tôi luôn thấy đó là một cách thực hành tốt nhất để sử dụng screenhoặc tmuxkhi thực hiện một thao tác loại này, chỉ trong trường hợp . Nhiều lần tôi không làm theo lời khuyên của chính mình và không thực hiện được điều này, nhưng thực sự nên sử dụng một trong những công cụ này để đảm bảo rằng công việc từ xa không bị hỏng vì phiên vỏ hoạt động của bạn bị ngắt kết nối bằng cách nào đó.

Tôi biết bạn muốn tìm ra nguyên nhân gốc rễ của rsyncvấn đề của bạn . Tuy nhiên, nếu điều này thực sự quan trọng, đây là hai cách giải quyết tuyệt vời mà bạn có thể thử nghiệm trong lúc này.

Tôi đã gặp vấn đề tương tự trên OSX El Capitan và đã khắc phục vấn đề này bằng cách nâng cấp lên rsync v3.11. Vấn đề đã xảy ra với tôi trên v2.6.9.

Kerberos chỉ để xác thực, điều đó sẽ không gây ra bất kỳ vấn đề nào sau khi bạn đã tạo kết nối thành công.

Bạn đã thử sử dụng daemon rsync chưa?

Các máy chủ của bạn trên cùng một mạng hay bạn có tường lửa / bộ định tuyến ở giữa không?

Bạn có thể thử thiết lập một phiên netcat giữa các máy chủ, đó là một cách đơn giản để thử nếu bạn có bất kỳ vấn đề kết nối nào giữa các máy chủ của mình.

Trên máy chủ đầu tiên:

nc -lk <port-number>

Và trên máy khách

nc <server> <port-number>

Bạn có thể để kết nối mở và xem kết nối có giữ được không, hoặc nếu bạn mất kết nối. Bạn cũng có thể thử viết một cái gì đó trên máy khách, thấy rằng nó kết thúc ở phía bên kia.

Bạn có một cái gì đó trên máy chủ từ xa ghi vào thiết bị xuất chuẩn . Điều này có thể là trong .profilehoặc .bash_profile. Nó có thể là một cái gì đó ít rõ ràng như sttyhoặc mesg. Nếu nghi ngờ, hãy sao chép bảng điểm vào câu hỏi của bạn về việc đăng nhập vào máy chủ (xác định lại tên máy chủ bằng mọi cách).

lần duy nhất tôi gặp sự cố như vậy với rsync, tôi đã theo dõi nó đến một cổng ethernet dự phòng trên một máy khác có cùng địa chỉ IP với máy chủ mục tiêu của tôi. Nếu rsync không ổn định, gần như chắc chắn đó là vấn đề về độ tin cậy của mạng hoặc (trong trường hợp của tôi).

Tôi gặp một vấn đề tương tự khi chạy rsynchoặc bằng tay (hoặc có cp, scphoặc trong Gnome Nautilus) sao chép các file lớn từ một máy tính để bàn Linux để một ARM thấp được hỗ trợ dựa trên Linux NAS qua mạng gigabit cáp (không có kerberostrong thiết lập của tôi). Các ổ NAS được chia sẻ bằng cách sử dụng sambavà được gắn trên máy khách bằng cách sử dụng cifs. Giải pháp cho tôi là gắn kết hệ thống tệp NAS từ máy khách mà không cần lưu vào bộ đệm (xem thêm trang man mount.cifs ):

sudo mount -t cifs //server.lan/somedir /mnt/somedir/ -o cache=none

Ngoài ra, khi gắn ổ NAS trên máy khách sử dụng gvfstrong nautilusvấn đề này sẽ không tồn tại khi sao chép các tệp lớn (nhưng điều đó không hoạt động kết hợp với rsyncmặc dù).

Làm cho Linux ghi vào hệ thống tệp mạng đồng thời với đĩa cục bộ đọc thêm chi tiết về lý do tại sao vấn đề này có thể xảy ra.

Chỉ cần nâng cấp các phiên bản rsync của bạn để đảm bảo chúng giống hệt nhau trên cả PC gửi và nhận. Xem câu trả lời của tôi ở đây: /server/883487/unable-to-rsync-due-to-broken-pipe/988794#988794 .