Tôi thường thấy mình gửi các thư mục có 10K - 100K tệp đến một máy từ xa (trong cùng một mạng trong khuôn viên trường).

Tôi chỉ tự hỏi nếu có lý do để tin rằng,

 tar + rsync + untar

Hoặc đơn giản

 tar (from src to dest) + untar

trong thực tế có thể nhanh hơn

rsync 

khi chuyển các tập tin lần đầu tiên .

Tôi quan tâm đến một câu trả lời giải quyết vấn đề trên trong hai tình huống: sử dụng nén và không sử dụng nó.

Cập nhật

Tôi vừa chạy một số thử nghiệm di chuyển 10.000 tệp nhỏ (tổng kích thước = 50 MB) và tar+rsync+untarnhanh hơn so với chạy rsynctrực tiếp (cả hai đều không nén).

Khi bạn gửi cùng một bộ tệp, rsyncphù hợp hơn vì nó sẽ chỉ gửi sự khác biệt. tarsẽ luôn gửi mọi thứ và điều này thật lãng phí tài nguyên khi có rất nhiều dữ liệu. Các tar + rsync + untarđánh mất lợi thế này trong trường hợp này, cũng như lợi thế của việc giữ các thư mục trong đồng bộ hóa với rsync --delete.

Nếu bạn sao chép các tệp lần đầu tiên, lần đầu tiên đóng gói, sau đó gửi, sau đó giải nén (AFAIK rsynckhông lấy đầu vào theo đường ống) thì cồng kềnh và luôn tệ hơn chỉ là rsyncing, vì dù sao rsynccũng sẽ không phải thực hiện bất kỳ nhiệm vụ tarnào.

Mẹo: rsync phiên bản 3 trở lên không có đệ quy gia tăng, nghĩa là nó bắt đầu sao chép gần như ngay lập tức trước khi đếm tất cả các tệp.

Mẹo2: Nếu bạn sử dụng rsynchơn ssh, bạn cũng có thể sử dụng một trong haitar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

hoặc chỉ scp

scp -Cr srcdir user@server:destdir

Quy tắc chung, giữ cho nó đơn giản.

CẬP NHẬT:

Tôi đã tạo 59M dữ liệu demo

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

và đã thử nghiệm nhiều lần chuyển tập tin đến một máy chủ từ xa (không phải trong cùng một lan), sử dụng cả hai phương thức

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

trong khi giữ các bản ghi riêng biệt từ các gói lưu lượng ssh được gửi

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

Trong trường hợp này, tôi không thể thấy bất kỳ lợi thế nào trong lưu lượng mạng ít hơn bằng cách sử dụng rsync + tar, được dự kiến ​​khi mtu mặc định là 1500 và trong khi các tệp có kích thước 10k. rsync + tar có lưu lượng truy cập được tạo nhiều hơn, chậm hơn trong 2-3 giây và để lại hai tệp rác phải được dọn sạch.

Tôi đã thực hiện các thử nghiệm tương tự trên hai máy trên cùng một lan và ở đó rsync + tar đã làm thời gian tốt hơn nhiều và lưu lượng mạng ít hơn nhiều. Tôi giả sử nguyên nhân của khung jumbo.

Có thể rsync + tar sẽ tốt hơn là chỉ rsync trên tập dữ liệu lớn hơn nhiều. Nhưng thật lòng mà nói tôi không nghĩ nó đáng để gặp rắc rối, bạn cần gấp đôi không gian ở mỗi bên để đóng gói và giải nén, và có một vài lựa chọn khác như tôi đã đề cập ở trên.

rsynccũng không nén. Sử dụng -zcờ. Nếu chạy qua ssh, bạn cũng có thể sử dụng chế độ nén của ssh. Cảm giác của tôi là mức độ lặp đi lặp lại không hữu ích; nó sẽ chỉ đốt cháy chu kỳ mà không có kết quả quan trọng. Tôi khuyên bạn nên thử nghiệm với rsyncnén. Có vẻ khá hiệu quả. Và tôi khuyên bạn nên bỏ qua việc sử dụng tarhoặc bất kỳ nén trước / sau nào khác.

Tôi thường sử dụng rsync như rsync -abvz --partial....

Tôi đã phải sao lưu thư mục nhà của mình vào NAS ngày hôm nay và bắt đầu cuộc thảo luận này, nghĩ rằng tôi sẽ thêm kết quả của mình. Câu chuyện dài, việc truy cập mạng vào hệ thống tệp mục tiêu nhanh hơn trong môi trường của tôi so với việc kết nối đến cùng một đích.

Môi trường: Máy nguồn i7 để bàn sử dụng ổ cứng SSD. Máy đích Synology NAS DS413j trên kết nối gigabit lan đến máy Nguồn.

Thông số kỹ thuật chính xác của bộ liên quan sẽ ảnh hưởng đến hiệu suất, và tôi không biết chi tiết về thiết lập chính xác của mình liên quan đến chất lượng phần cứng mạng ở mỗi đầu.

Các tệp nguồn là thư mục ~ / .cache của tôi chứa 1,2Gb gồm các tệp rất nhỏ.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Tôi giữ 1a và 1b là các bước hoàn toàn riêng biệt chỉ để minh họa cho nhiệm vụ. Đối với các ứng dụng thực tế, tôi muốn giới thiệu những gì Gilles đã đăng ở trên liên quan đến đầu ra tar của ống thông qua ssh cho một quy trình xử lý trên máy thu.

Thời gian:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

Rõ ràng là rsync hoạt động kém đáng kinh ngạc so với hoạt động tar, có lẽ có thể được quy cho cả hiệu suất mạng được đề cập ở trên.

Tôi khuyên mọi người muốn sao lưu số lượng lớn các tệp nhỏ, như sao lưu thư mục chính, hãy sử dụng phương pháp tar. rsync có vẻ là một sự lựa chọn rất kém Tôi sẽ quay lại bài đăng này nếu có vẻ như tôi đã không chính xác trong bất kỳ thủ tục nào của mình.

Nick

Sử dụng rsync để gửi một kho lưu trữ tar như được hỏi thực sự sẽ là một sự lãng phí hoặc nguồn tài nguyên, vì bạn đã thêm một lớp xác minh vào quy trình. Rsync sẽ kiểm tra chính xác tệp tar, khi bạn muốn kiểm tra từng tệp riêng lẻ. (Không có ích khi biết rằng tệp tar có thể bị lỗi ở phía gửi đã cho thấy hiệu ứng tương tự ở đầu nhận). Nếu bạn đang gửi một kho lưu trữ, ssh / scp là tất cả những gì bạn cần.

Một lý do bạn có thể phải chọn gửi một kho lưu trữ là nếu tar bạn chọn có thể bảo vệ nhiều hơn các đặc biệt của hệ thống tệp, chẳng hạn như Danh sách điều khiển truy cập hoặc Siêu dữ liệu khác thường được lưu trữ trong Thuộc tính mở rộng (Solaris) hoặc Ressource Fork (MacOS ). Khi xử lý những vấn đề như vậy, mối quan tâm chính của bạn sẽ là công cụ nào có thể lưu giữ tất cả thông tin liên quan đến tệp trên hệ thống tệp nguồn, cung cấp hệ thống tệp đích cũng có khả năng theo dõi chúng.

Khi tốc độ là mối quan tâm chính của bạn, nó phụ thuộc rất nhiều vào kích thước tệp của bạn. Nói chung, vô số các tệp nhỏ sẽ mở rộng rất nhiều so với rsync hoặc scp, vì tất cả các gói mạng riêng lẻ sẽ bị lãng phí, trong đó một tệp tar sẽ bao gồm một vài trong số chúng trong tải dữ liệu của một gói mạng. Thậm chí tốt hơn nếu tệp tar được nén, vì các tệp nhỏ rất có thể sẽ nén tốt hơn toàn bộ so với riêng lẻ. Theo tôi biết, cả rsync và scp đều không tối ưu hóa khi gửi toàn bộ các tệp đơn lẻ như trong một lần chuyển ban đầu, mỗi tệp chiếm toàn bộ khung dữ liệu với toàn bộ chi phí giao thức của nó (và lãng phí nhiều hơn cho việc kiểm tra qua lại). Tuy nhiên Janecektuyên bố điều này chỉ đúng với scp, cho rằng rsync sẽ tối ưu hóa lưu lượng mạng nhưng với chi phí xây dựng các cấu trúc dữ liệu khổng lồ trong bộ nhớ. Xem bài viết Chuyển tập tin hiệu quả, Janecek 2006 . Vì vậy, theo ông, vẫn đúng là cả scp và rsync đều có quy mô xấu trên các tệp nhỏ, nhưng vì những lý do hoàn toàn khác nhau. Đoán tôi sẽ phải đào vào các nguồn cuối tuần này để tìm hiểu.

Đối với sự phù hợp thực tế, nếu bạn biết rằng bạn đang gửi hầu hết các tệp lớn hơn, sẽ không có nhiều sự khác biệt về tốc độ và sử dụng rsync có thêm lợi ích là có thể tiếp nhận vị trí của nó khi bị gián đoạn.

Postcriptum : Ngày nay, ndist dường như chìm vào quên lãng, nhưng trước thời của rsync, nó là một công cụ rất có khả năng và được sử dụng rộng rãi (an toàn khi sử dụng qua ssh, nếu không an toàn). Tôi sẽ không hoạt động tốt như rsync mặc dù nó không tối ưu hóa để chỉ chuyển nội dung đã thay đổi. Sự khác biệt chính của nó đối với rsync nằm ở cách nó được cấu hình và cách các quy tắc cập nhật tệp được phát âm.

Đối với các thư mục nhỏ (nhỏ như trong không gian đĩa đã sử dụng), nó phụ thuộc vào chi phí kiểm tra thông tin tệp cho các tệp được đồng bộ hóa. Một mặt, rsynctiết kiệm thời gian chuyển các tệp chưa sửa đổi, mặt khác, nó thực sự phải chuyển thông tin về mỗi tệp.

Tôi không biết chính xác nội bộ của rsync. Việc các số liệu thống kê tệp có gây ra độ trễ hay không tùy thuộc vào cách rsynctruyền dữ liệu - nếu số liệu thống kê tệp được truyền từng cái một, thì RTT có thể giúp tar + rsync + gỡ bỏ nhanh hơn.

Nhưng nếu bạn có, giả sử 1 GiB dữ liệu, rsync sẽ nhanh hơn, trừ khi kết nối của bạn thực sự nhanh!

Tôi đã phải di chuyển một vài terabyte dữ liệu trên toàn quốc, chính xác một lần. Như một thử nghiệm, tôi đã thực hiện hai trong số các lần chuyển bằng cách sử dụng rsyncvà ssh/tarđể xem chúng so sánh như thế nào.

Kết quả:

• rsync chuyển các tập tin với tốc độ trung bình 2,76 megabyte mỗi giây.
• ssh/tar chuyển các tệp với tốc độ trung bình 4,18 megabyte mỗi giây.

Chi tiết: Dữ liệu của tôi bao gồm hàng triệu tệp nén .gz, kích thước trung bình là 10 megabyte nhưng một số dữ liệu trên một gigabyte. Có một cấu trúc thư mục nhưng nó bị lấn át bởi kích thước của dữ liệu bên trong các tệp. Nếu tôi có hầu hết mọi thứ để làm, tôi sẽ chỉ sử dụng rsyncnhưng trong trường hợp này, đó ssh/tarlà một giải pháp chức năng.

Công việc của tôi rsyncbao gồm:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

trong đó fileList.txt là một danh sách dài các tên đường dẫn tương đối của các tệp ở phía bên kia. (Tôi nhận thấy rằng việc --compressnày không hiệu quả đối với các tệp nén sau khi tôi bắt đầu nhưng tôi sẽ không quay lại khởi động lại.)

Tôi bắt đầu khác với ssh và tar có:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Bạn sẽ quan sát bản sao này tất cả mọi thứ, xin lỗi đây không phải là một so sánh 100% táo với táo.

Tôi nên thêm rằng trong khi tôi đang sử dụng mạng công ty nội bộ, tôi phải thông qua một trung gian để đến máy tính nguồn dữ liệu. Thời gian ping từ máy tính mục tiêu của tôi đến trung gian là 21 ms và từ trung gian đến nguồn dữ liệu là 26 ms. Điều này là giống nhau cho cả hai lần chuyển.

Kết nối SSL thông qua trung gian được thực hiện thông qua ~/.ssh/configmục:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Thời gian này:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"