The question has been partly answered, but that's still not what I'm exactly looking for. See for Update 1 down bere

I'm planning to encrypt some filesystems with VeraCrypt and LUKS, but my fears are that if a single problem happens, I would not be able to mount the partitions again thus losing all the data stored inside them. (due to damaged sectors/blocks, power failure during a writing operation, file system errors, etc)

Also, VeraCrypt may have forked TrueCrypt's repair tools, but I'm not counting on it and looking more about real cases.

I also know about RAID and backups/vaults, but it's not what I'm looking for.

So the question is: How resilient are encrypted partitions themselves with VeraCrypt and LUKS ?

Update 1:

My question is more about the resilience of the encrypted partition and its data, rather than about saving the master key, metadata or headers. The problem is similar to a solid 7zip archive: if a single bit is damaged in the middle, then you lose the whole archive.

Will encrypted partitions be as vulnerable ? (excluding master key, metadata and headers)

PS: Sorry if I don't answer right away, I'm working and travelling around the world -thus making this post related- and I often face time-squeezing business. But, I will definitely answer back for sure.

4 Answers 4


In practice, it's almost as resilient with encryption as without it, as long you backup the master key and metadata properly.

Apart of metadata, the corruption would affect just the block of the corrupted bit, in most cases just 16 bytes of it.

For most of the situations of data corruption, with the key and tools (like your password and Veracrypt/LUKS), you have the same access as a non encrypted disk, just like you do normally with everyday use of a encrypted disk. Encryption would only add a additional step (open a encrypted partition) than ordinary. So in this case, it behaviors just like non encrypted data.

With Veracrypt or Luks, you have to store the master key in the disk, that is encrypted with your password. Damaging this sector(s) would cause permanent data lost. This can be easily solved with master key backup (few kilobytes in size), something easy to do with both software, and it's highly recommended for everyone.

Details about non meta data

Both Veracrypt and Luks uses XTS today. In this mode, it's calculated a key for every block. In a simplification, to encrypt block i you use a key generated with the Master Keys and the block number. So, the encryption of one block in independent of another. If you corrupt some information, it will be restrict to that block.

In XTS, it breaks the block in sub-blocks (of 16 bytes usually) and creates a key, and encrypt that sub-block with it. That means that if we change a bit on it, only this 16 bytes would be affected.

As as test, changing a single bit in a Luks volume, it changes 16 bytes of the original file to gibberish, but the others 496 stills unchanged. In a 7zip file, it uses a stream method, that all bytes are chained, so one byte change would affect all the remaining ones - this is not the case here.

Some consider this a problem, as you can know with precision of 16 bytes when and where you change a plain text, comparing just the encrypted data.

More interesting information about this can be found on these links:




Details about Master Key


LUKS have a few sectors in the beginning of the partition (or disk) with metadata, storing encryption methods, other parameters and 8 key slots. For encrypting and decrypting the disk, it uses a Master Key, a big random number generated when create a LUKS container. To store it, it encrypt the Master Key with your password, through iterating a cryptographic hash function many times over the password and generating a specific key for that slot. You can have 8 different passwords for the same disk, each one encrypting the master key with a different password in a slot. When you change the password, It's as simple as encrypting the Master Key, and not changing all the partition.

So, when this slots and metadata is corrupted, you can't recover the master key that is really used to decrypt, losing all data on disk. This is a easy way to fast destroy all your data. But if you have a backup of the Volume Header, it's pretty easy to recover it.

Below is a copy of LUKS FAQ about backup extracted from https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery

6.2 How do I backup a LUKS header?

While you could just copy the appropriate number of bytes from the start of the LUKS partition, the best way is to use command option "luksHeaderBackup" of cryptsetup. This protects also against errors when non-standard parameters have been used in LUKS partition creation. Example:

cryptsetup luksHeaderBackup --header-backup-file <file> <device>

To restore, use the inverse command, i.e.

cryptsetup luksHeaderRestore --header-backup-file <file> <device>

If you are unsure about a header to be restored, make a backup of the current one first! You can also test the header-file without restoring it by using the --header option for a detached header like this:

cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>

If that unlocks your keys-lot, you are good. Do not forget to close the device again.

Under some circumstances (damaged header), this fails. Then use the following steps:

First determine the master-key size:

cryptsetup luksDump <device>

gives a line of the form

MK bits:        <bits>

with bits equal to 256 for the old defaults and 512 for the new defaults. 256 bits equals a total header size of 1'052'672 Bytes and 512 bits one of 2MiB. (See also Item 6.12) If luksDump fails, assume 2MiB, but be aware that if you restore that, you may also restore the first 1M or so of the filesystem. Do not change the filesystem if you were unable to determine the header size! With that, restoring a too-large header backup is still safe.

Second, dump the header to file. There are many ways to do it, I prefer the following:

head -c 1052672 <device>  >  header_backup.dmp


head -c 2M <device>  >  header_backup.dmp

for a 2MiB header. Verify the size of the dump-file to be sure. To restore such a backup, you can try luksHeaderRestore or do a more basic

cat header_backup.dmp  >  <device>


Veracrypt is similar to LUKS. I'm not used with it as I was with Truecrypt, but the general idea holds.

Veracrypt just have one key slot, so you can't have more than one password at the same time. But you can have a hidden volume: it's stores the metadata in the end of the partition (or disk or file). The hidden volume has a different Master Key and will use the end of the partition as overlapped space. The idea that you should backup is the same. This can be done with Tools -> Backup Volume Header and Tools -> Restore Volume Header. With system encryption, it used to create a bootable disk with key backup that recovers the Truecrypt loader and keys if any damage happens. It's done before it encrypt anything, and As far as I know Veracrypt continue doing the same way.

For more details see this link https://veracrypt.codeplex.com/wikipage?title=Program%20Menu

Security Considerations About Backup Keys

If you have a leaked password for example, and changes the volume password to a new, strong and secure one, someone with access to the backup would stills being able to decrypt the files with the old password. The backup is basically the Master Key encrypted with the (old) password. So, when changing passwords, it's also needed to make a new backup and destroy the older ones. And destroying data permanently can be very trick.

For every backup you have with that password, is a possible way to decrypt data with that password. This can be used in Veracrypt for instance, using a "Universal Password" (like in a corporation), backing it up and changing for another password. So the IT dept. could recover the access to that volume even if someone lost the password (think as a Master Password, but don't confuse with the Master Key from earlier).

Final Thoughts (TL;DR)

The probability of damaging the specific sector with the master key is less likely than you having a complete disk failure. So if this data is important, you should have a backup of it instead just the volume headers (Master Key).

And corruption of data spread little (16 bytes), resulting acceptable for most uses.

So a bad block in the middle of the partition or disk would affect only that block. And a few bits errors in a sector is restricted to that sector, and won't even affect totally a 512 bytes sector.

Update (23/01/2017): add more information based on the OP comments.

  • 1
    Wow, that was a very extensive and informative answer, thanks a lot ! However, my question is more about the resilience of the encrypted partition and the datas itselves, rather than the master key and metadata. The problem is similar to a solid 7zip archive: if a single bit is damaged in the middle, then you lose the whole archive. Will encrypted partitions will act the same ? (master key and metadata excluded)
    – X.LINK
    Jan 15, 2017 at 17:38
  • Dear sir, I am a little bit confused about backup the master key and metadata in your words. Does the command cryptsetup luksHeaderBackup in your post do the job? You mentioned this command will backup LUKS header. Thus what is the relationship between master key and metadata and LUKS header? Thanks a lot.
    – sgon00
    Sep 9, 2020 at 13:32
  • 1
    @sgon00: There is a long time I wrote this. But you gotta it right. The LUKS header contains the metadata, that is the master key, cypher name & mode, hash method, salt, iterations, etc. You need all this to be able to decrypt it, and this command saves it. It worths mention that the master key is saved encrypted in slots. You have 8 slots and in each of them the master key is encrypted based on the password key you type (or key file) when unlocking it, that allows to unlock with different passwords. The command cryptsetup luksDump gives all this info. Sep 10, 2020 at 2:03
  • @AllanDeamon Got it, Thanks a lot for your answer.
    – sgon00
    Sep 10, 2020 at 7:51

I have compiled below some information about the resiliency of VeraCrypt/TrueCrypt containers.

From Veracrypt data corruption :

TC/VC store the volume header at two place: at the start and at the end of volume. The one at the start is the main one and the one at the end is for backup. This mechanism is usually sufficient to enable access when a part of the drive is damaged or corrupted because the damage is often local. if the damage occur to both the start and the end of the drive, then the drive is almost certainly dead.

Please note that in case of a damaged or corrupted drive, you'll have the same data loss as when you don't use encryption. This means that even if you are able to mount the volume, there data read may be corrupted. So, always think about data backup because encryption doesn't protect from data corruption.

From the VeraCrypt FAQ :

What will happen when a part of a VeraCrypt volume becomes corrupted?

In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by VeraCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by VeraCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected.

What do I do when the encrypted filesystem on my VeraCrypt volume is corrupted?

File system within a VeraCrypt volume may become corrupted in the same way as any normal unencrypted file system. When that happens, you can use filesystem repair tools supplied with your operating system to fix it. In Windows, it is the 'chkdsk' tool. VeraCrypt provides an easy way to use this tool on a VeraCrypt volume: Right-click the mounted volume in the main VeraCrypt window (in the drive list) and from the context menu select 'Repair Filesystem'.

Small data corruption should then have only local effect and will not destroy the entire container. However, I advise against encrypting a whole volume/partition and especially the system drive, as recovery can then be more complicated. Take good backups, especially for the volume header. And remember that, just as for a real disk or folder, corruption in the disk/file headers may make data recuperation difficult and may require advanced utilities.

I believe that LUKS does not have a second header on disk, so you have to be even more careful about keeping a backup.

  • I've read those but this is still a bit confusing. Apart from recoveries made through containers' headers and filesystems inside containers, does it means that a bad sector right in the middle of a container itself won't make it completely dead and impossible to mount ? As I may understand it right, does a ciphertext block works exactly like inside a non-solid 7-zip archive/unencrypted ext3 still mountable have physical bad sectors ?
    – X.LINK
    Jan 18, 2017 at 15:56
  • I can't speak for encrypted volumes, but changing a single bit in an encrypted cyphertext will just spit out garbage for the entire block. The block size might be 128 bytes or 256 bytes or 4kb. It won't prevent the rest of the cyphertext from being decrypted. There's no way for the encryption algorithm to know the garbage is bad. There is no checksum or anything (for AES-CBC). If that block was inside a text file, it will just look like garbage in Notepad. If it was part of the directory structure, then the file system will look garbled and require chkdsk.
    – Chloe
    Jan 18, 2017 at 16:53
  • @X.LINK: A bad bit will corrupt its whole "sector" of 16 bytes. Depending of where that sector is located, the result can be nothing if it falls in an unused area, or garbage in that spot in the file or, in the worst case, bad directory structure requiring the use of recovery utilities. This is very similar to a physical disk where you have unused sectors, file data and disk tables, and your backup should follow similar guidelines.
    – harrymc
    Jan 23, 2017 at 13:07

The following relates to your section "Update 1".

Both Veracrypt and LUKS provide the same resilience towards random data sector failures assuming that you successfully mounted the partitions.

The reason is that they both act as an additional layer below the operating system read/write function of sectors. They provide sector-oriented encryption. Both encryption schemes do not change the on-disk structure layout.

This way of operation does not correspond to the limitations of the storage technique of a solid 7z archive. It even does not correspond to that of a normal 7z archive.

In addition to that please keep in mind the situation before mounting. The anti-forensic techniques of LUKS blow up metadata to 3 sectors (header) + 4000 (stripes) * 16 (assumed max key length) * 8 (key slots) bytes = 512003 bytes =~ 1000 sectors. There is no backup of this structure available.

Compare this to a standard Veracrypt header (only data, no hidden partition) with 512 byte = 1 sector. In addition to that, there is a backup header at the end of the file system.

The header resilience of LUKS compared to Veracrypt is about 0,1% as one bad sector used by the LUKS header can make the disk unreadable. I am writing "can" as I am unable to determine reading the on-disk format specification if such a shot will affect all 8 available key slots or just one.


Thanks to all the answers people provided, the definitive answer is 100% complete.

I don't have much time these days, so i'll edit my "own" answer later. Since all the answers people gave here are completely useful, this will just be a recap of what they said, plus my findings too.

Anyway, here's one of my findings that will debunk a lot of confusion I met, and it mostly concerned... what block means, since it's a term that is overly and mistakenly used:


Also, you'll find a "standard" way to talk about things here, and avoid the 'block' confusion:


In short terms, you can change an encrypted block containing the word "400" to be "800". This means encrypted block-level layer is completely non-solid, instead of believing that "this will act like a normal filesystem" (ie Veracrypt FAQ).

Also, I should have stumbled upon that link two months ago:


Since VeraCrypt is a TrueCrypt's fork, it will certainly works the same.


Any additional answer is still welcome, and will be added to my "own" answer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .