82

I'm archiving data from one server to another. Initially I started a rsync job. It took 2 weeks for it to build the file list just for 5 TB of data and another week to transfer 1 TB of data.

Then I had to kill the job as we need some down time on the new server.

It's been agreed that we will tar it up since we probably won't need to access it again. I was thinking of breaking it into 500 GB chunks. After I tar it then I was going to copy it across through ssh. I was using tar and pigz but it is still too slow.

Is there a better way to do it? I think both servers are on Redhat. Old server is Ext4 and the new one is XFS.

File sizes range from few kb to few mb and there are 24 million jpegs in 5TB. So I'm guessing around 60-80 million for 15TB.

edit: After playing with rsync, nc, tar, mbuffer and pigz for a couple of days. The bottleneck is going to be the disk IO. As the data is striped across 500 SAS disks and around 250 million jpegs. However, now I learnt about all these nice tools that I can use in future.

Improve this question
21
  • 1
    possible duplicate of linux to linux, 10TB transfer?
    – D34DM347
    Sep 9, 2015 at 15:40
  • 2
    One option is creating the compressed tar files on an external drive and moving that to the new system. The extra disk will speed up creating the tar files (won't be writing to existing disks in the system, possibly while trying to read 15TB from them) and doesn't tie up the new server.
    – Brian
    Sep 9, 2015 at 15:47
  • 4
    Is there a better way to do it? - Yeah, Windows Server 2012 R2 DFS replication would prepare that in about 10 hours. And it would sync changes, and pick up where it left off after reboots.
    – TessellatingHeckler
    Sep 9, 2015 at 17:15
  • 27
    @TessellatingHeckler: so you suggest OP migrates from Redhat to Windows before archiving?
    – Thomas Weller
    Sep 9, 2015 at 22:22
  • 12
    @ThomasWeller They asked "is there a better way?", and there is. I make no recommendation that they use the better way. They're free to use commands in a pipe which can't recover from interruption, won't verify the file content, can't report copy status, can't use previously copied blocks to avoid copying parts of files, has no implicit support low-priority copying, can't be paused, has no mention of copying ACLs, and needs someone to stay logged in to run it. Anyone else following along, however, might be interested - or prompted to say "x does that on Linux".
    – TessellatingHeckler
    Sep 9, 2015 at 23:52

12 Answers 12

Reset to default
68

I have had very good results using tar, pigz (parallel gzip) and nc.

Source machine:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Destination machine:

To extract:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

To keep archive:

nc source_machine_ip 9876 > smallstuff.tar.gz

If you want to see the transfer rate just pipe through pv after pigz -d!

Improve this answer
12
  • 3
    FYI, you can replace pigz with gzip or remove it altogether, but the speed will be significantly slower.
    – h0tw1r3
    Sep 9, 2015 at 17:25
  • 10
    How can this be accepted if OP has already tried tar and pigz? I don't understand...
    – Thomas Weller
    Sep 9, 2015 at 22:26
  • 5
    @ThomasWeller where did you get that he's tried pigz? From the question it looks like he's only tried rsync so far, and was considering using tar to split and bundle the data. Especially if he hasn't used the -z/--compress option on rsync, pigz could theoretically help significantly.
    – Doktor J
    Sep 9, 2015 at 22:38
  • 2
    @ThomasWeller yes indeed I already tried tar and pigz but not nc. I was using ssh so it added a lot more overhead.
    – lbanz
    Sep 10, 2015 at 8:45
  • 2
    @lbanz that simply means that tar isn't producing data fast enough for pigz to use much CPU for compression. Reading lots of small files involves many more syscalls, many more disk seeks, and a lot more kernel overhead than reading the same number of bytes of larger files, and it looks like you're simply bottlenecking at a fundamental level.
    – hobbs
    Sep 11, 2015 at 3:54
21

I'd stick to the rsync solution. Modern (3.0.0+) rsync uses incremental file list, so it does not have to build full list before transfer. So restarting it won't require you to do whole transfer again in case of trouble. Splitting the transfer per top or second level directory will optimize this even further. (I'd use rsync -a -P and add --compress if your network is slower than your drives.)

Improve this answer
3
  • I'm using rsync 2.6.8 on the old server. As it is one of those boxes where we're not allowed to install/update anything as stated by the vendor or it voids the warranty. I might update it and see if it is any quicker.
    – lbanz
    Sep 10, 2015 at 8:43
  • 18
    Find (or build) a statically-linked rsync binary and just run it from your home. Hopefully that won't ruin no warranty.
    – Fox
    Sep 10, 2015 at 9:09
  • How about unison? How does it compare to rsync?
    – Gwyneth Llewelyn
    Dec 9, 2018 at 18:28
15

Set up a VPN (if its internet), create a virtual drive of some format on the remote server (make it ext4), mount it on the remote server, then mount that on the local server (using a block-level protocol like iSCSI), and use dd or another block-level tool to do the transfer. You can then copy the files off the virtual drive to the real (XFS) drive at your own convenience.

Two reasons:

  1. No filesystem overhead, which is the main performance culprit
  2. No seeking, you're looking at sequential read/write on both sides
Improve this answer
3
  • 3
    Bypassing the filesystem is good. Copying block-level of a read-write mounted filesystem is a really bad idea. Unmount or mount read-only first.
    – JB.
    Sep 10, 2015 at 12:38
  • Having a 15TB copy sucks, too. It means the new server needs minimum 30.
    – Arthur Kay
    Sep 10, 2015 at 12:41
  • 4
    If the server is using LVM, one could do a read-only snapshot of the filesystem and copy it instead. Space overhead only for the changes in the filesystem that happen while the snapshot is read.
    – liori
    Sep 10, 2015 at 17:51
10

If the old server is being decommissioned and the files can be offline for a few minutes then it is often fastest to just pull the drives out the old box and cable them into the new server, mount them (back online now) and copy the files to the new servers native disks.

Improve this answer
1
  • 2
    It's about 1PB of 2TB drives so it is way too much.
    – lbanz
    Sep 10, 2015 at 8:40
3

Use mbuffer and if it is on a secure network you can avoid the encryption step.

Improve this answer
3

(Many different answers can work. Here is another one.)

Generate the file list with find -type f (this should finish in a couple of hours), split it to small chunks, and transfer each chunk using rsync --files-from=....

Improve this answer
3

Have you considered sneakernet? With that, I mean transfering everything onto the same drive, then physically moving that drive over.

about a month ago, Samsung unveiled a 16 TB drive (technically, it's 15.36 TB), which is also an SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard-drive-16tb

I think this drive would just about do for this. You'd still have to copy all the files, but since you don't have network latency and probably can use SATA or a similarly fast technique, it should be quite a lot faster.

Improve this answer
2

If there is any chance to get high success ratio when deduplication, I would use something like borgbackup or Attic.

If not, check the netcat+tar+pbzip2 solution, adapt the compression options according to your hardware - check what is the bottleneck (CPU? network? IO?). The pbzip2 would nicely span across all CPUs, giving better performance.

Improve this answer
3
  • lzma (xz) decompresses faster than bzip2, and does well on most input. Unfortunately, xz's multithread option isn't implemented yet.
    – Peter Cordes
    Sep 10, 2015 at 3:40
  • Usually the compression stage needs more horsepower than decompression, so if the CPU is the limiting factor, pbzip2 would result in better overall performance. Decompression shouldn't affect the process, if both machines are similar.
    – neutrinus
    Sep 10, 2015 at 7:45
  • Yes, my point was it's a shame that there isn't a single-stream multi-thread lzma. Although for this use-case, of transferring whole filesystems of data, pigz would prob. be the slowest compressor you'd want to use. Or even lz4. (There's a lz4mt multi-threaded-for-a-single-stream available. It doesn't thread very efficiently (spawns new threads extremely often), but it does get a solid speedup)
    – Peter Cordes
    Sep 10, 2015 at 9:14
2

You are using RedHat Linux, so this wouldn't apply, but as another option:

I've had great success using ZFS to hold millions of files as inodes aren't an issue.

If that was an option for you, you could then take snapshots and use zfs to send incremental updates. I've had a lot of success using this method to transfer as well as archive data.

ZFS is primarily a Solaris filesystem, but can be found in the illumos (open source fork of Sun's OpenSolaris). I know there has also been some luck at using ZFS under BSD and Linux (using FUSE?)--but I have no experience on trying that.

Improve this answer
1
  • 3
    There has been a non-FUSE native Linux port of ZFS for quite a while now: zfsonlinux.org
    – EEAA
    Sep 10, 2015 at 18:52
1

Start an rsync daemon on the target machine. This will speedup the transfer process a lot.

Improve this answer
0

Try juicesync?

juicesync local/path user@host:port:path --threads=50

you can also use --worker and --manager mode to start more jobs.

Also you can try rclone(sftp).

Improve this answer
-1

You can do this with just tar and ssh, like this:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Or, if you want to keep individual files:

tar zcf - <your files> | ssh <destination host> "tar zxf -"

Improve this answer
1
  • 1
    It will not deduplicate, no way to resume, compressing using only one CPU.
    – neutrinus
    Sep 11, 2015 at 19:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .