First make sure that the logical volume is not mounted. If it is and you want to make a "hot copy", create a snapshot first and use this instead:
lvcreate --snapshot --name transfer_snap --size 1G
I have to transfer a lot of data (7TB) between two 1Gbit connected Servers, so i needed the fastes possible way to do so.
Should you use SSH?
Using ssh is out of question, not because of its encryption (if you have a CPU with AES-NI support, it does not hurt so much) but because of its network buffers. Those are not scaling well. There is a patched Ssh version that addresses this problem, but as there are no precompiled packages, its not very convenient.
When transferring raw disk images, it is always advisable to use compression. But you do not want the compression to become a bottleneck. Most unix compression tools like gzip are single-threaded, so if the compression saturates one CPU, it will be a bottleneck. For that reason, i always use pigz, an gzip variant that uses all CPU cores for compression. And this is necessary of you want to go up to and above GBit speeds.
As said before, ssh is slow. If you have an AES-NI CPU, this should not be a bottleneck. So instead of using ssh, we can use openssl directly.
To give you an Idea of the speed impact of the components, here are my results. Those are transfer speeds between two production systems reading and writing to memory. You actual results depend on network speed, HDD speed and source CPU speed! Im doing this to show that there at least is no huge performance drop.
Simple nc dd:
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s
+pigz compression level 1 (speed gain depends on actual data):
network traffic: 2.52GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s
+pigz compression level 5:
network traffic: 2.43GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s
+compression level 1 + openssl encryption:
network traffic: 2.52GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s
Conclusion: using compressing gives a noticeable speedup, as it reduces the data size a lot. This is even more important if you have slower network speeds. When using compression, watch your cpu usage. if the usage gets maxed out, you can try without it. Using compression as only a small impact on AES-NI systems, imho only because it steals some 30-40% cpu from the compression.
If you are transferring a lot of data like me, you do not want to have it interrupted by an network disconnect of your ssh client, so you better start it with screen on both sides. This is just a note, i will not write a screen tutorial here.
Install some dependencies (on source and destination):
apt install pigz pv netcat-openbsd
then create a volume on the destination with the same size as the source. If unsure, use lvdisplay on the source to get the size and create the target i.e.:
lvcreate -n lvname vgname -L 50G
next, prepare the destination for receiving the data:
nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname
and when ready, start the transfer on the Source:
pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1
Note: If you are transferring the data locally or do not care about encryption, just remove the Openssl part from both sides. If you care, asdkjn2hb is the Encryption key, you should change it.