Cách sao chép nhanh chóng một số lượng lớn tệp giữa hai máy chủ

Tôi cần chuyển một lượng lớn mp3 giữa hai lần phục vụ (Ubuntu). Ý tôi là rất lớn, khoảng một triệu tệp trung bình 300K. Tôi đã thử với scpnhưng nó sẽ mất khoảng một tuần. (khoảng 500 KB / s) Nếu tôi chuyển một tệp bằng HTTP, tôi nhận được 9-10 MB / s, nhưng tôi không biết cách chuyển tất cả chúng.

Có cách nào để chuyển tất cả chúng một cách nhanh chóng?

Tôi muốn giới thiệu tar. Khi cây tập tin đã tương tự, rsync hoạt động rất tốt. Tuy nhiên, vì rsync sẽ thực hiện nhiều lần phân tích trên mỗi tệp và sau đó sao chép các thay đổi, nên chậm hơn nhiều so với tar cho bản sao ban đầu. Lệnh này có thể sẽ làm những gì bạn muốn. Nó sẽ sao chép các tập tin giữa các máy, cũng như duy trì cả quyền và quyền sở hữu người dùng / nhóm.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Theo nhận xét của Mackffy bên dưới, đây là lệnh bạn sẽ sử dụng cho rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Ổ cứng ngoài và giao hàng chuyển phát nhanh trong cùng ngày.

Tôi sẽ sử dụng rsync.

Nếu bạn đã xuất chúng qua HTTP với danh sách thư mục có sẵn, bạn cũng có thể sử dụng wget và đối số --mirror.

Bạn đã thấy rằng HTTP nhanh hơn SCP vì SCP đang mã hóa mọi thứ (và do đó làm tắc nghẽn CPU). HTTP và rsync sẽ di chuyển nhanh hơn vì chúng không mã hóa.

Dưới đây là một số tài liệu về cách thiết lập rsync trên Ubuntu: https://help.ubfox.com/community/rsync

Những tài liệu đó nói về rsync đường hầm qua SSH, nhưng nếu bạn chỉ di chuyển dữ liệu trên một mạng LAN riêng thì bạn không cần SSH. (Tôi giả sử bạn đang sử dụng mạng LAN riêng. Nếu bạn nhận được 9-10 MB / giây qua Internet thì tôi muốn biết bạn có loại kết nối nào!)

Dưới đây là một số tài liệu rất cơ bản khác sẽ cho phép bạn thiết lập máy chủ rsync không an toàn tương đối (không phụ thuộc vào SSH): http://transamrit.net/docs/rsync/

Không có nhiều thảo luận, sử dụng netcat, dao swissarmy mạng. Không có giao thức, bạn đang sao chép trực tiếp vào ổ cắm mạng. Thí dụ

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

Với rất nhiều tệp nếu bạn thực hiện với rsync, tôi sẽ cố gắng lấy phiên bản 3 trở lên ở cả hai đầu . Lý do là một phiên bản nhỏ hơn sẽ liệt kê mọi tệp trước khi bắt đầu chuyển. Tính năng mới được gọi là đệ quy tăng dần .

Một thuật toán đệ quy gia tăng mới hiện được sử dụng khi rsync đang nói chuyện với phiên bản 3.x khác. Điều này bắt đầu quá trình chuyển nhanh hơn (trước khi tất cả các tệp đã được tìm thấy) và cần ít bộ nhớ hơn. Xem tùy chọn --recursive trong trang chủ để biết một số hạn chế.

rsync, giống như những người khác đã được đề nghị. Nếu chi phí CPU từ mã hóa là một nút cổ chai, hãy sử dụng một thuật toán ít tốn CPU hơn, như blowfish. Ví dụ như một cái gì đó như

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

Khi di chuyển 80 TB dữ liệu (hàng triệu tệp nhỏ) vào ngày hôm qua, việc chuyển đổi rsyncsang tar được chứng minh là nhanh hơn nhiều , vì chúng tôi đã ngừng cố gắng

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

và chuyển sang tarthay thế ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Vì các máy chủ này nằm trên cùng một mạng LAN, đích đến được gắn NFS trên hệ thống nguồn, đang thực hiện việc đẩy. Không làm cho nó nhanh hơn nữa, chúng tôi quyết định không bảo quản các atimetệp:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

Đồ họa dưới đây mô tả sự khác biệt của sự thay đổi từ rsync sang tar được thực hiện. Đó là ý tưởng của sếp tôi và đồng nghiệp của tôi đã thực hiện nó và thực hiện bài viết tuyệt vời trên blog của anh ấy . Tôi chỉ thích hình ảnh đẹp . :)

Khi sao chép một số lượng lớn tệp, tôi thấy rằng các công cụ như tar và rsync hoạt động kém hiệu quả hơn mức cần thiết do chi phí mở và đóng nhiều tệp. Tôi đã viết một công cụ mã nguồn mở có tên là fast-archiver nhanh hơn tar cho các tình huống này: https://github.com/replicon/fast-archiver ; nó hoạt động nhanh hơn bằng cách thực hiện nhiều thao tác tập tin đồng thời.

Đây là một ví dụ về lưu trữ nhanh so với tar trên bản sao lưu của hơn hai triệu tệp; lưu trữ nhanh mất 27 phút để lưu trữ, so với tar mất 1 giờ 23 phút.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Để truyền tệp giữa các máy chủ, bạn có thể sử dụng lưu trữ nhanh với ssh, như thế này:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Tôi cũng sử dụng tar thông qua netcatcách tiếp cận, ngoại trừ tôi thích sử dụng socat- nhiều năng lượng hơn để tối ưu hóa cho tình huống của bạn - ví dụ, bằng cách điều chỉnh mss. (Ngoài ra, hãy cười nếu bạn muốn, nhưng tôi thấy các socatđối số dễ nhớ hơn vì chúng nhất quán). Vì vậy, đối với tôi, điều này rất phổ biến gần đây khi tôi chuyển mọi thứ sang máy chủ mới:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Bí danh là tùy chọn.

Một cách khác là Unison . Có thể hiệu quả hơn một chút so với Rsync trong trường hợp này và việc thiết lập trình nghe dễ dàng hơn một chút.

Có vẻ như có thể có một vài lỗi chính tả trong câu trả lời hàng đầu. Điều này có thể hoạt động tốt hơn:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• Hệ thống tệp mạng (NFS) và sau đó sao chép chúng với bất cứ thứ gì bạn thích, ví dụ Midnight Commander (mc), Nautilus (từ gnome). Tôi đã sử dụng NFS v3 với kết quả tốt.
• Samba (CIFS) và sau đó sao chép các tệp với bất cứ điều gì bạn muốn, nhưng tôi không biết nó hiệu quả như thế nào.
• HTTP với wget --mirrornhư Evan Anderson đã đề xuất hoặc bất kỳ ứng dụng khách http nào khác. Hãy cẩn thận để không có bất kỳ liên kết tượng trưng khó chịu hoặc các tệp chỉ mục gây hiểu lầm. Nếu tất cả những gì bạn có là MP3, bạn nên an toàn.
• rsync . Tôi đã sử dụng nó với kết quả khá tốt và một trong những tính năng hay của nó là bạn có thể làm gián đoạn và tiếp tục chuyển tiền sau đó.

Tôi đã nhận thấy rằng những người khác đã khuyến nghị sử dụng netcat . Dựa trên kinh nghiệm của tôi với nó, tôi có thể nói rằng nó chậm so với các giải pháp khác.

Nhờ câu trả lời tuyệt vời của Scott Pack (tôi không biết làm thế nào với ssh trước đây), tôi có thể cung cấp cải tiến này (nếu bashlà vỏ của bạn). Điều này sẽ thêm nén song song, chỉ báo tiến trình và kiểm tra tính toàn vẹn trên liên kết mạng:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvlà một chương trình xem tiến trình tốt đẹp cho đường ống của bạn và pigzlà một chương trình gzip song song sử dụng nhiều luồng như CPU ​​của bạn theo mặc định (tôi tin tối đa 8 tối đa). Bạn có thể điều chỉnh mức độ nén để phù hợp hơn với tỷ lệ của CPU với băng thông mạng và trao đổi nó với pxz -9evà pxz -dnếu bạn có nhiều CPU hơn băng thông. Bạn chỉ phải xác minh rằng hai khoản tiền khớp với nhau khi hoàn thành.

Tùy chọn này hữu ích cho số lượng rất lớn dữ liệu cũng như mạng có độ trễ cao, nhưng không hữu ích nếu liên kết không ổn định và bị rớt. Trong những trường hợp đó, rsync có lẽ là sự lựa chọn tốt nhất vì nó có thể tiếp tục.

Đầu ra mẫu:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Đối với thiết bị khối:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Rõ ràng, hãy đảm bảo rằng chúng có cùng kích thước hoặc giới hạn với số đếm =, bỏ qua =, tìm kiếm =, v.v.

Khi tôi sao chép các hệ thống tệp theo cách này, trước tiên tôi sẽ thường dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefssử dụng hầu hết không gian không sử dụng, giúp tăng tốc độ xfer.

Tôi không nghĩ bạn sẽ làm gì tốt hơn scp trừ khi bạn cài đặt card mạng nhanh hơn. Nếu bạn đang làm điều này qua internet, điều đó sẽ không giúp đỡ.

Tôi khuyên bạn nên sử dụng rsync . Nó có thể không nhanh hơn nữa, nhưng ít nhất nếu nó thất bại (hoặc bạn tắt nó vì mất quá nhiều thời gian), bạn có thể tiếp tục nơi bạn rời đi lần sau.

Nếu bạn có thể kết nối trực tiếp 2 máy bằng ethernet gigabit, đó có thể sẽ là cách nhanh nhất.

Đối với 100Mb / giây, thông lượng lý thuyết là 12,5 MB / s, vì vậy với tốc độ 10 MB / giây, bạn đang làm khá tốt.

Tôi cũng sẽ lặp lại đề xuất để làm rsync, có thể thông qua ssh. Cái gì đó như:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

Với tốc độ 100Mb / giây, CPU của bạn sẽ có thể xử lý mã hóa / giải mã mà không ảnh hưởng đáng kể đến tốc độ dữ liệu. Và nếu bạn làm gián đoạn luồng dữ liệu, bạn sẽ có thể tiếp tục từ nơi bạn rời đi. Coi chừng, với "hàng triệu" tệp, startup sẽ mất một lúc trước khi nó thực sự chuyển bất cứ thứ gì.

Tôi đã gặp phải điều này, ngoại trừ việc tôi đang chuyển nhật ký của Oracle.

Đây là sự cố

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

Tôi đã sử dụng FTP rất thành công (trong đó thành công lớn tương đương với ~ 700Mb / giây trên mạng Gb). Nếu bạn nhận được 10 MB (tương đương với 80Mb / giây), có thể có điều gì đó không ổn.

Bạn có thể cho chúng tôi biết gì về nguồn và đích của dữ liệu? Có phải ổ đĩa đơn đến ổ đĩa đơn? RAID sang USB?

Tôi biết câu hỏi này đã có câu trả lời, nhưng nếu mạng của bạn chậm như vậy trên cáp chéo Gb / s, một cái gì đó hoàn toàn cần được sửa.

Bạn đã không đề cập đến việc hai máy trên cùng một mạng LAN hay nếu một kênh bảo mật (nghĩa là sử dụng SSH) là bắt buộc, nhưng một công cụ khác bạn có thể sử dụng là netcat .

Tôi sẽ sử dụng như sau trên máy nhận:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Sau đó về phía gửi:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Nó có những ưu điểm sau:

• Không có chi phí CPU cho mã hóa mà ssh có.
• Việc gzip -1cung cấp nén ánh sáng mà không làm bão hòa CPU để nó đánh đổi tốt, mang lại một chút nén trong khi duy trì thông lượng tối đa. (Có lẽ không có lợi cho dữ liệu MP3, nhưng không gây hại.)
• Nếu bạn có thể phân vùng các tệp thành các nhóm, bạn có thể chạy song song hai hoặc nhiều đường ống và thực sự đảm bảo bạn đang bão hòa băng thông mạng của mình.

ví dụ,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Ghi chú:

• Dù bạn chuyển bằng cách nào, tôi có thể sẽ chạy rsync hoặc unison sau đó để đảm bảo bạn có mọi thứ.
• Bạn có thể sử dụng tarthay vì cpionếu bạn thích.
• Ngay cả khi bạn kết thúc bằng ssh, tôi sẽ đảm bảo rằng nó không sử dụng bất kỳ thao tác nén nào và gzip -1thay vào đó tự mình đi qua để tránh bão hòa CPU. (Hoặc ít nhất là đặt NénLevel thành 1.)

Một scp đơn giản với các tùy chọn phù hợp sẽ dễ dàng đạt 9-10 MB / s qua mạng LAN:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

Với các tùy chọn đó, có khả năng thông lượng trở nên nhanh hơn gấp 4 hoặc 5 lần so với không có tùy chọn (mặc định)

Nếu bạn có máy chủ ftp ở phía src, bạn có thể sử dụng ncftpget từ trang web ncftp . Nó hoạt động hoàn hảo với các tệp nhỏ vì nó sử dụng tar bên trong.

Một so sánh cho thấy điều này: di chuyển các tệp nhỏ 1,9 GB (33926 tệp)

1. Sử dụng scp mất 11m59s
2. Sử dụng rsync mất 7m10s
3. Sử dụng ncftpget mất 1m20s

Bạn cũng có thể thử sử dụng lệnh BBCP để thực hiện chuyển khoản của mình. Đó là một ssh song song đệm thực sự hét lên. Chúng tôi thường có thể nhận được 90% + tỷ lệ dòng với điều kiện chúng tôi có thể giữ cho đường ống được cung cấp.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Thông thường, chúng tôi cố gắng thực sự để tránh phải di chuyển xung quanh. Chúng tôi sử dụng các nhóm ZFS mà chúng tôi luôn có thể "thêm" thêm dung lượng đĩa vào. Nhưng đôi khi ... bạn chỉ cần di chuyển công cụ. Nếu chúng ta có một hệ thống tập tin "trực tiếp" có thể mất hàng giờ (hoặc ngày) để sao chép ngay cả khi phát nổ hoàn toàn .. chúng tôi sẽ thực hiện quy trình gửi hai bước zfs:

1. Tạo ảnh chụp nhanh ZFS và chuyển sang nhóm mới trên máy mới. Hãy để nó mất chừng nào nó cần.
2. Tạo ảnh chụp nhanh thứ hai và gửi dưới dạng gia tăng. Ảnh chụp nhanh gia tăng chỉ bao gồm bộ thay đổi (nhỏ hơn nhiều) kể từ lần đầu tiên, do đó nó đi qua tương đối nhanh.
3. Khi ảnh chụp nhanh tăng dần được hoàn thành, bạn có thể chuyển bản gốc và cắt sang bản sao mới và "thời gian ngừng hoạt động ngoại tuyến" của bạn được giữ ở mức tối thiểu.

Chúng tôi cũng gửi các bãi rác zfs của chúng tôi trên BBCP ... nó cũng tối đa hóa việc sử dụng mạng của chúng tôi và giảm thiểu thời gian chuyển.

BBCP có sẵn miễn phí, bạn có thể google nó và đó là một trình biên dịch trực tiếp. Chỉ cần sao chép nó vào / usr / local / bin của bạn trên cả máy src và máy đích và nó sẽ hoạt động khá nhiều.

Tôi đoán câu trả lời của tôi hơi muộn ở đây, nhưng tôi đã có những trải nghiệm tốt khi sử dụng mc (Midnight Commander) trên một máy chủ để kết nối qua SFTP với máy chủ khác.

Tùy chọn kết nối qua FTP nằm trong menu "Trái" và "Phải", bằng cách nhập địa chỉ như thế này:

/#ftp:name@server.xy/

hoặc là

/#ftp:name@ip.ad.dr.ess/

Bạn có thể điều hướng và thực hiện các thao tác tệp gần giống như trên hệ thống tệp cục bộ.

Nó có một tùy chọn tích hợp để thực hiện sao chép ở chế độ nền, nhưng tôi thích sử dụng lệnh màn hình và tách ra khỏi màn hình trong khi mc đang sao chép (tôi nghĩ nó cũng chạy nhanh hơn).

Để @scottpack trả lời tùy chọn rSync

Để hiển thị tiến trình tải lên, hãy sử dụng '--progess' làm tùy chọn sau -avW trong lệnh như được hiển thị bên dưới.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Dưới đây là một điểm chuẩn nhanh để so sánh một số kỹ thuật,

• Nguồn là CPU Intel (R) Xeon (R) 4 nhân E5-1620 @ 3.60GHz với 250 Mbps và ổ đĩa SATA
• Đích đến là CPU Intel (R) Xeon (R) 6 nhân E-2136 @ 3.30GHz với băng thông 1 Gbps và ổ SSD

Số lượng tệp: 9632, Tổng kích thước: 814 MiB, Kích thước trung bình: 84 KiB

• RSYNC: 1m40.570
• RSYNC + MÁY TÍNH: 0m26.519s
• TAR + NETCAT: 1m58.763s
• TAR + MÁY TÍNH + NETCAT: 0m28.009s

Lệnh cho tar / netcat là:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsync hoặc bạn có thể muốn tar nó để tất cả trong một tệp và sau đó scp. Nếu bạn thiếu không gian đĩa, bạn có thể đặt tar trực tiếp lên ssh trong khi nó được tạo.

Nếu bạn đang gửi qua các tệp MP3 và các tệp nén khác, bạn sẽ không nhận được nhiều từ bất kỳ giải pháp nào cố gắng nén thêm các tệp đó. Giải pháp sẽ là một cái gì đó có thể tạo ra nhiều kết nối giữa cả hai máy chủ và do đó gây thêm căng thẳng về băng thông giữa hai hệ thống. Một khi điều này đạt đến mức tối đa, sẽ không có nhiều thứ có thể đạt được mà không cải thiện phần cứng của bạn. (Ví dụ, thẻ mạng nhanh hơn giữa các máy chủ đó.)

Tôi đã thử một vài công cụ để sao chép tệp 1GB Kết quả như sau: HTTP nhanh nhất, với wget -c nc thứ hai trong dòng scp chậm nhất và vài lần thất bại. Không có cách nào để tiếp tục rsync sử dụng ssh làm phụ trợ, do đó, kết quả tương tự. Để kết luận, tôi sẽ truy cập http với wget -bqc và cho nó một chút thời gian. Mong rằng điều này sẽ giúp

Tôi đã phải sao chép đĩa BackupPC vào một máy khác.

Tôi đã sử dụng rsync.

Máy có bộ nhớ 256 MB.

Thủ tục tôi làm theo là:

• thực hiện rsyncmà không có -H(mất 9 giờ)
• Khi rsync kết thúc, tôi đã đồng bộ cpoolthư mục và bắt đầu với pcthư mục; Tôi cắt chuyển.
• sau đó khởi động lại rsyncbằng -Hcờ và tất cả các tệp cứng được liên kết trong pcthư mục đã được chuyển chính xác (quy trình tìm thấy tất cả các tệp thực trong cpoolđó và sau đó được liên kết với pcthư mục) (mất 3 giờ).

Cuối cùng, tôi có thể xác minh df -mrằng không có thêm không gian đã được chi tiêu.

Bằng cách này, tôi đã giải quyết vấn đề với bộ nhớ và rsync. Tất cả thời gian tôi có thể xác minh hiệu suất bằng cách sử dụng hàng đầu và trên đỉnh và cuối cùng tôi đã chuyển 165GB dữ liệu.