This seems to be the most important question. What will be the block size for dd ? It needs to match, so that an exact copy can be restored without any problems.
What will be thecountparameter fordd ?
What do I put as my count parameter ? Again, it needs to match my filesystem exactly.
Can I usegzipin some way to compress the image ?
I will be storing the image on my external HDD, thus the more I can save on space the better.
How am I going to restore the image ?
I am doing this because I want to migrate to thin LVMs.
How do I restore the image to a logical volume after I have the image ? I want to restore it to a logical volume.
As you can see there is no mention of my LVM devices here.
Also reading the man page for blockdev you come across this peculiar sentence:
--getbsz
Print blocksize in bytes. This size does not describe device topology. It's size used internally by kernel and it maybe modified (for example) by
filesystem driver on mount.
Should I use the kernel block size or the filesystem block size ?
Most sources on the net mention the LVM blocksize is calculated from the filesystem block size, which makes sense to me.
See for example:
If I were you, I would just try it. Normally we stage these kinds of moves, so I would just pick the params I think are correct and try to clone it; using trial-and-error, on my staging platform.
Do you have a reason for this? We use 'dd' as you say to get an exact mirror of the filesystem, warts and all. Do you have software keys you are trying to copy? Is there a need for inode numbers not to change? Or what?
In this context (clone a disk) it needs to be the same, or for better performance a multiple of, the disk sector size (typically 512 or 1024). In this context it will control how many sectors are hoovered up per payload. Larger block size will mean less I/O work and therefore a bit faster.
You won't need to specify 'count' if you are copying the whole filesystem device. By default, 'dd' will copy the whole device (and report the count to you at the end). You would use 'count' to only copy a given number of sectors.
You would have to use 'dd' to restore it. The 'dd' image will copy the whole filesystem sector-by-sector including free space (so it will be larger than a 'tar' or 'cpio').
I assume that you are regularly backing up your production filesystem, so if you needed to disaster recover (oh, I mean clone it) you would restore from that.
If you are using LUKS disk encryption you need to check whether 'dd' would copy encrypted disk sectors or de-encrypt them first. I'm not sure how you would recover from a 'dd' file which was sector-by-sector encrypted. You need to check that.
Perhaps someone else on this forum may know what will happen in this instance.