0

What is the most complete way to backup/restore entire /dev/sdX (to/from a file) including device partition table and partition flags, all possible metadata, owners, file permissions, ACLs, creation/access/change times, file attributes (like append only (a) or immutable (i)), xattrs, access rights flags (like setuid, setgid, sticky bit), filesystem-specific attributes, etc if I want to get compressed backup file? /dev/sdX's partitions can be formatted in ext4, fat, exfat, ntfs, different file system for each partition or not.

The easiest way is to use dd or even dump utility but we will get big uncompressed file (.iso, .img, .bin, etc) as a result. But what's next?

I see some options like to use dd | gzip or dd | tar pipe but I'm not sure that this will save all the necessary data in view of this answer. Вesides, I'm not sure gzip can offer the most efficient compression mechanism.

Other option is to use the most modern, efficient and multi-threaded compression tools like xz. But man says

After successfully compressing or decompressing the file, xz copies the owner, group, permissions, access time, and modification time from the source file to the target file. If copying the group fails, the permissions are modified so that the target file doesn't become accessible to users who didn't have permission to access the source file. xz doesn't support copying other metadata like access control lists or extended attributes yet.

Does it matter in case I use it in a pipe with dd which copies blocks not files? Is the sudo dd if=/dev/sdX | xz -9 --threads=0 --keep -v > output.img.xz pipe enough to save all specified data? And a pipe like xz -dck output.img.xz | dd of=/dev/sdX status=progress to restore the backup? Do I need to worry about metadata (attributes, ACLs, etc)?

I'm not sure that i don't in the view of this quote from xz's manual:

--keep Don't delete the input files. Since xz 5.2.6, this option also makes xz compress or decompress even if the input is a symbolic link to a regular file, has more than one hard link, or has the setuid, setgid, or sticky bit set. The setuid, setgid, and sticky bits are not copied to the target file.

Do I need to worry about command options like --xattrs, --acls in the case when I use a dd | tar pipe?

Finally, do I have to always specify the bs attribute of the dd command if I backup entire /dev/sdX and use a compressed file as an intermediate backup location if I want to get the most identical copy of the original device as a result of recovery? In this case, which bs size to prefer?

Maybe I need to prefer fsarchiver or something like them instead of dd, but it is less commonly used and not released as v1.x yet.

4
  • dd will always copy blocks, not files as asked for in your question. Since /dev/sdX can contain many different file sytems or raw partitions, no file system utilities will apply. tar is not really appropriate since you're feeding it a single input stream. Pick the compression utility of choice to use. Attributes, ACL's, etc, will be embedded in the raw file system that you're backing up so you don't have to worry specifically about them. However, you might consider backing up individual file systems using their specific & preferred utilities instead of looking for a raw dump of the dev.
    – doneal24
    Sep 19, 2022 at 18:06
  • @doneal24, thanks for the answer. > Attributes, ACL's, etc, will be embedded in the raw file system that you're backing up so you don't have to worry specifically about them. I also don't sure that they will be restored fully and correctly, not juct backed up.
    – Monerig
    Sep 19, 2022 at 19:06
  • All attributes will be embedded in the raw disk blocks that you're backing up. Information that was contained in the raw blocks will be restored when you copy back the raw blocks. Using dd does imply that you're restoring back to a similar (or larger) device. Using file-system specific tools will ensure that you are managing the attributes in a way that can be restored to a general device. dd doesn't know or care about filesystem attributes or even know that it is backing up a file system.
    – doneal24
    Sep 19, 2022 at 19:12
  • Regarding dd, the default block size is 512 (bytes). Setting larger block sizes will speed-up the backup, and you may set bs=4096 (or bs=4k) (which is the physical sector size of most HDDs). You may set even larger values, but preferably stick with powers of 2.
    – PierU
    Sep 23, 2022 at 6:03

0

You must log in to answer this question.

Browse other questions tagged .