How to clone serveral TB data of multiple small files into PVE LXC/VM?

ceweithr

New Member
Feb 28, 2021
2
0
1
35
I am here to seek for a solution, but I don't know whereis the question threads so I put it here.

I've install a PVE on a server with 24TB LVM Storage. Now I have to transfer about 10TB data from an external RAID Storage in ext4 filesystem. Actually, the data is storage in /dev/sda1, but only take 9.7TB space and has 14TB free space. I would like to copy all the 9.7TB data into a PVE LXC mount point or PVE VM disk.

Now I am facing a big problem: the data are many small files, so if I use `rsync` or `cp` or even combined with `tar`, the speed are only less than 30MB/s, while the RAID5 consists of 3 disks can provide about 200MB+/s write/read speed. So I am looking for a much more efficiently way to make it. And here to seek for help, here are my thought:

## use dd to make whole disk clone

- first, use gparted to resize /dev/sda1 into 10TB
- second, use `dd` command to make a whole partition clone, but in other case like `dd if=/dev/sda1 of=/dev/sdb1 bs=xx count=xx` does not work here. I don't know what is the `of` in an LXC container, and where I should execute this command.

If any of you can help me out? I would very appreciate it.
 
you can allocate a raw volume with pvesm alloc ... with the right size on the target storage (you can create a test container on your storage to see how the volume ID should look if you are not sure). with pvesm path VOLID you should get the right (output) path for dd - but please verify, there are some storages (mainly for VMs) where you need to activate the volume first, or the printed path is not a real path but something that only qemu understands (i.e., check with stat that the path exists and is a raw image/block device!). then finally you can add it as a mountpoint to your container pct set VMID -mpX VOLID,mp=/path/in/container.

some notes:
- I'd test it with a small test image/disk first to avoid lots of wasted time
- PVE containers expect the filesystem directly on the volume, no partition tables or the like
- if the container is unprivileged (highly recommended) but the source FS is a 'normal' one, you'd need to fixup all the owners after copying. likely still faster than doing a file-based copy, but just so you know ;)