Skip to main content
Stuff
Source Link
Chris Davies
  • 128.4k
  • 16
  • 179
  • 324

I don't believe the veracrypt layer has anything whatsoever to do with the disk space issue. Veracrypt is a block layer that knows nothing about filesystems. Ext4 is a filesystem that sits on top of a block device. If you're not getting disk space back then it's a filesystem issue.

Considerations other than block size (discussed an in another answer) are sparse files and hard linked files being copied as separates. Both are managed by flags to rsync; both are ignored by your selection of flags. You can validate this by comparing the disk usage from these two commands:

du -hsx /media/veracrypt1 du -hsxl --apparent-size /media/veracrypt1 

In your linked question you talk about backing up an entire system. In such cases you need to be careful to ignore memory-backed filesystems such as /dev and often /tmp. However, here you're using directory paths so I will continue to use those here

rsync -aHSaxHS /media/veracrypt1/ /media/veracrypt2 

Notes:

  1. The sparse flag will not replace existing files with sparse equivalents - you would need to process those yourself or delete them first.
  2. Likewise rsync will not hard link files that are the same but not already hard linked; you would have to delete both beforehand.
  3. Your original command would have created /media/veracrypt2/veracrypt1. By suffixing / to the source directory path you perform a copy directly to the destination without first creating a subdirectory named as the source.

I don't believe the veracrypt layer has anything whatsoever to do with the disk space issue. Veracrypt is a block layer that knows nothing about filesystems. Ext4 is a filesystem that sits on top of a block device. If you're not getting disk space back then it's a filesystem issue.

Considerations other than block size (discussed an in another answer) are sparse files and hard linked files being copied as separates. Both are managed by flags to rsync; both are ignored by your selection of flags.

In your linked question you talk about backing up an entire system. In such cases you need to be careful to ignore memory-backed filesystems such as /dev and often /tmp. However, here you're using directory paths so I will continue to use those here

rsync -aHS /media/veracrypt1/ /media/veracrypt2 

Notes:

  1. The sparse flag will not replace existing files with sparse equivalents - you would need to process those yourself or delete them first.
  2. Likewise rsync will not hard link files that are the same but not already hard linked; you would have to delete both beforehand.
  3. Your original command would have created /media/veracrypt2/veracrypt1. By suffixing / to the source directory path you perform a copy directly to the destination without first creating a subdirectory named as the source.

I don't believe the veracrypt layer has anything whatsoever to do with the disk space issue. Veracrypt is a block layer that knows nothing about filesystems. Ext4 is a filesystem that sits on top of a block device. If you're not getting disk space back then it's a filesystem issue.

Considerations other than block size (discussed an in another answer) are sparse files and hard linked files being copied as separates. Both are managed by flags to rsync; both are ignored by your selection of flags. You can validate this by comparing the disk usage from these two commands:

du -hsx /media/veracrypt1 du -hsxl --apparent-size /media/veracrypt1 

In your linked question you talk about backing up an entire system. In such cases you need to be careful to ignore memory-backed filesystems such as /dev and often /tmp. However, here you're using directory paths so I will continue to use those here

rsync -axHS /media/veracrypt1/ /media/veracrypt2 

Notes:

  1. The sparse flag will not replace existing files with sparse equivalents - you would need to process those yourself or delete them first.
  2. Likewise rsync will not hard link files that are the same but not already hard linked; you would have to delete both beforehand.
  3. Your original command would have created /media/veracrypt2/veracrypt1. By suffixing / to the source directory path you perform a copy directly to the destination without first creating a subdirectory named as the source.
Source Link
Chris Davies
  • 128.4k
  • 16
  • 179
  • 324

I don't believe the veracrypt layer has anything whatsoever to do with the disk space issue. Veracrypt is a block layer that knows nothing about filesystems. Ext4 is a filesystem that sits on top of a block device. If you're not getting disk space back then it's a filesystem issue.

Considerations other than block size (discussed an in another answer) are sparse files and hard linked files being copied as separates. Both are managed by flags to rsync; both are ignored by your selection of flags.

In your linked question you talk about backing up an entire system. In such cases you need to be careful to ignore memory-backed filesystems such as /dev and often /tmp. However, here you're using directory paths so I will continue to use those here

rsync -aHS /media/veracrypt1/ /media/veracrypt2 

Notes:

  1. The sparse flag will not replace existing files with sparse equivalents - you would need to process those yourself or delete them first.
  2. Likewise rsync will not hard link files that are the same but not already hard linked; you would have to delete both beforehand.
  3. Your original command would have created /media/veracrypt2/veracrypt1. By suffixing / to the source directory path you perform a copy directly to the destination without first creating a subdirectory named as the source.