it-swarm-vi.tech

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 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 scp nhưng 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?

96
nicudotro

Tôi muốn giới thiệu tar. Khi cây tập tin đã tương tự, rsync thực hiện 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
119
Scott Pack

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

38
Adam

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/

17
Evan Anderson

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 -
16
Icapan

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 để có phiên bản 3 trở lên ở cả hai đầ. 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ế.

8
Kyle Brandt

rsync, giống như những người khác đã được đề nghị. Nếu chi phí hoạt động của 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ụ. cái gì đó như

rsync -ax -e 'ssh -c blowfish' /local/path [email protected]:/remote/path

7
janneb

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

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

và chuyển sang tar thay vào đó ...

# 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 Đẩy. Không làm cho nó nhanh hơn nữa, chúng tôi đã quyết định không lưu giữ atime của các tệ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 từ rsync sang tar được thực hiện. Đó là của sếp ý tưởng của tôi và đồng nghiệp cả hai đã thực hiện nó và làm cho tuyệt vời viết lên blog của anh ấy . Tôi chỉ thích ảnh đẹp . :)

rsync_vs_tar

7
Philip Durbin

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ụ 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 [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
4
mfenniak

Tôi cũng sử dụng phương pháp tar thông qua netcat, 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 đối số socat 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.

3
R. Francis Smith
  • Hệ thống tệp mạng (NFS) và sau đó sao chép chúng với bất cứ điều gì bạn thích, ví dụ: Chỉ huy nửa đêm (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ả đến mức nào.
  • [~ # ~] http [~ # ~] với wget --mirror as 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.

2
Cristian Ciupitu

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'
2
retracile

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 bash là Shell 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 [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv là chương trình xem tiến trình Nice cho đường ống của bạn và pigz là 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ệ CPU với băng thông mạng và trao đổi nó với pxz -9epxz -d nế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 lượng dữ liệu rất lớn 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 [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Rõ ràng, đả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 hệ thống tập tin theo cách này, tôi sẽ thường đầu tiên dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs đến 0 hầu hết không gian không sử dụng, giúp tăng tốc độ xfer.

2
Daniel Santos

Một cách khác là nison . Có thể hiệu quả hơn một chút so với Rupync 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.

2
Adam D'Amico

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 (tức 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ó.
  • Các gzip -1 cung cấp nén nhẹ mà không bão hòa CPU để nó có sự đá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 nison sau đó để đảm bảo bạn có mọi thứ.
  • Bạn có thể sử dụng tar thay vì cpio nếu bạn thích.
  • Ngay cả khi bạn kết thúc bằng ssh, tôi sẽ đảm bảo nó không sử dụng bất kỳ thao tác nén nào và chuyển qua gzip -1 thay vào đó để tránh bão hòa CPU. (Hoặc ít nhất là đặt NénLevel thành 1.)
1
Evan

Nếu bạn có máy chủ ftp ở bên src, bạn có thể sử dụng ncftpget từ trang 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
1
Ali Nikneshan

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ó diễn ra 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.

1
C. Shamis

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:[email protected]/

hoặc là

/#ftp:[email protected]/

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).

1
w-sky

Để @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

enter image description here

1
Dinesh Sunny

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 [email protected]:/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)

1
user57125

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.

1
Brent

Đố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 [email protected]$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ì.

1
David Mackintosh

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 ~ 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.

1
Matt Simmons

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 -
1
Antares

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ủ đó.)

0
Wim ten Brink

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 rsync mà không cần -H (mất 9 giờ)
  • khi rsync kết thúc, tôi đã đồng bộ thư mục cpool và bắt đầu với thư mục pc; Tôi cắt chuyển.
  • sau đó khởi động lại rsync với -H cờ và tất cả các tệp cứng được liên kết trong thư mục pc đã đượ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 thư mục pc) ( mất 3 giờ).

Cuối cùng, tôi có thể xác minh bằng df -m rằ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.

0
Hector

Tôi đã thử 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

0
Mijo

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.

0
Adam Gibbins