{"id":4864,"date":"2026-06-07T00:03:08","date_gmt":"2026-06-06T15:03:08","guid":{"rendered":"https:\/\/blog.id774.net\/entry\/?p=4864"},"modified":"2026-06-06T01:29:01","modified_gmt":"2026-06-05T16:29:01","slug":"a-practical-lifecycle-guide-to-operating-luks-encrypted-disks","status":"publish","type":"post","link":"https:\/\/blog.id774.net\/entry\/2026\/06\/07\/4864\/","title":{"rendered":"A Practical Lifecycle Guide to Operating LUKS Encrypted Disks"},"content":{"rendered":"

Operating an encrypted disk is not a task that ends when luksFormat succeeds. A LUKS device may look correct immediately after creation, but long-term recoverability depends on conditions that change over time: storage media age, operating system upgrades, cryptsetup behavior, cryptographic defaults, key handling, keyfile custody, emergency passphrases, systemd configuration, LVM layering, filesystem health, and the operator\u2019s ability to reconstruct the procedure years later. With an unencrypted disk, partial recovery may remain possible as long as the filesystem metadata can still be interpreted. With an encrypted block device, the data payload can remain physically present while becoming operationally unrecoverable because the LUKS header, a required key slot, a keyfile, an emergency passphrase, crypttab, fstab, LVM layout, mapper name, or mount procedure has been lost.<\/p>\n

This article treats LUKS encrypted disks as long-lived operational assets rather than one-time setup targets. A previous article framed long-term encrypted disk operation as a resilience problem involving LUKS1 and LUKS2, CBC-ESSIV and XTS, PBKDF2 and Argon2id, legacy TrueCrypt assets, media preservation, migration, and retirement[1]<\/a>. The point was not that every old configuration is immediately dangerous or that every asset should be converted to the newest format at any cost. The point was that encrypted storage remains usable only when its opening path, header, key material, device identity, boot configuration, inspection cycle, migration criteria, and retirement criteria are managed together. This article turns that design principle into a concrete operational procedure.<\/p>\n

cryptsetup is the primary user-space tool used to manage Linux encrypted block devices, including LUKS, plain dm-crypt, loop-AES, TrueCrypt\/VeraCrypt-style volumes, BitLocker, and FileVault2 formats[2]<\/a>. At the kernel layer, dm-crypt is a device-mapper target that transparently encrypts block devices[3]<\/a>. This distinction matters. cryptsetup commands may manipulate a LUKS header, open a mapper device, test a passphrase, add a key slot, back up metadata, or close a mapping. They do not all act on the same layer. A stable procedure must therefore separate the physical device, the LUKS header, the unlocked mapper device, the filesystem, the mount point, and any LVM layer.<\/p>\n

The practical objective is not to memorize scattered cryptsetup commands. The objective is to make encrypted disk operation reproducible. Before each operation, the operator should know what object is being touched, what condition is expected, what failure means, and what must be recorded afterward. The cryptsetup manual defines the available actions[4]<\/a>, but real operation requires those actions to be connected to ordering, inventory, verification, recovery, and retirement. A command that is harmless in one layer may be destructive in another layer, and a procedure that works today may be unrecoverable years later if the operational context is not preserved.<\/p>\n

\n

1. Manage the encrypted disk as a lifecycle<\/h2>\n

The first rule is that luksFormat is the beginning of the lifecycle, not the end of the work. After initial formatting come opening, filesystem creation, mounting, key slot management, header backup, crypttab and fstab integration, periodic checks, migration, recovery, and retirement. The Arch and Debian manual pages both present cryptsetup as a tool for managing encrypted devices, not merely creating them[5]<\/a>[6]<\/a>. A LUKS device that can be opened today is not automatically a LUKS device that can be opened five years from now.<\/p>\n

This lifecycle view is necessary because encrypted storage fails differently from ordinary filesystems. A filesystem can be damaged but still partially readable. An encrypted block device can be internally intact but practically inaccessible if the correct header, key material, and opening path are unavailable. The operational goal is therefore not merely confidentiality. The goal is controlled confidentiality over time: unauthorized users cannot open the device, while legitimate future operators still can.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Lifecycle stage<\/th>\nMain operations<\/th>\nOperational meaning<\/th>\n<\/tr>\n<\/thead>\n
Creation<\/td>\nIdentify the target, run luksFormat, open the device, create a filesystem, and mount it.<\/td>\nBuild a usable encrypted filesystem without destroying the wrong device.<\/td>\n<\/tr>\n
Routine use<\/td>\nOpen, mount, synchronize, unmount, and close in a fixed order.<\/td>\nKeep daily use reproducible and prevent stale mappings or unsynchronized writes.<\/td>\n<\/tr>\n
Inspection<\/td>\nUse luksDump, status, lsblk, blkid, e2fsck, fsck, and SMART checks.<\/td>\nCompare the actual device state with the inventory and detect drift, damage, or configuration mismatch.<\/td>\n<\/tr>\n
Key management<\/td>\nAdd, test, remove, and document key slots.<\/td>\nControl the set of valid opening paths without deleting the last usable one.<\/td>\n<\/tr>\n
Preservation and recovery<\/td>\nBack up headers, preserve keyfiles, test emergency passphrases, and prefer read-only rescue before repair.<\/td>\nMaintain recovery conditions when media, metadata, or configuration fails.<\/td>\n<\/tr>\n
Migration and retirement<\/td>\nCreate a new target, synchronize, verify, change the old role, reuse media, or erase.<\/td>\nMove away from obsolete or unreliable configurations without losing recovery paths prematurely.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

These stages are connected. A device identification mistake during creation invalidates every later step. Confusing open and mount makes recovery diagnosis difficult. Losing the distinction between the LUKS UUID and the filesystem UUID breaks crypttab and fstab reasoning. Adding key slots without recording their purpose creates unmanaged access paths. Retiring old media without confirming migration and alternate recovery routes turns cleanup into data loss. The lifecycle model exists to prevent these failures from being treated as isolated accidents.<\/p>\n

\n

2. Identify the target before every destructive operation<\/h2>\n

The most dangerous mistake in encrypted disk operation is usually not choosing the wrong cipher. It is writing to the wrong block device. luksFormat, mkfs, erase, header restore, partitioning, and wiping operations can all destroy existing data if the target is wrong. Device names such as \/dev\/sda, \/dev\/sdb, and \/dev\/sdc are not stable enough to be trusted as long-term identities. They can change with boot order, attachment order, USB bridge behavior, or hardware replacement. Red Hat\u2019s LUKS documentation also emphasizes identifying encrypted devices and using persistent identifiers such as UUIDs in system configuration[7]<\/a>.<\/p>\n

The first inspection point should be lsblk -f. This command shows block devices, partitions, filesystem types, UUIDs, and mount points in a hierarchy. The operator should confirm the expected capacity, whether the target is a whole disk or a partition, whether it already has a filesystem, whether it is already a crypto_LUKS device, whether it is part of LVM, and whether it is mounted. If MOUNTPOINTS contains a value, the device is in use and destructive operations must stop until the reason is understood.<\/p>\n

1
<\/div><\/td>
lsblk -f<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

When reading lsblk -f, distinguish the whole disk from its partitions. A name such as \/dev\/sdb refers to the entire disk, while \/dev\/sdb1 refers to the first partition. Encrypting a whole disk and encrypting a partition are both possible designs, but they are not interchangeable operationally. The chosen boundary affects inventory, crypttab entries, recovery procedures, and whether partition metadata remains outside the encrypted container.<\/p>\n\n\n\n\n\n\n\n\n\n
Check<\/th>\nWhere to look<\/th>\nDecision<\/th>\n<\/tr>\n<\/thead>\n
Capacity<\/td>\nSIZE column<\/td>\nConfirm that the candidate matches the expected disk capacity.<\/td>\n<\/tr>\n
Filesystem type<\/td>\nFSTYPE column<\/td>\nLook for existing ext4, vfat, crypto_LUKS, LVM2_member, or other signatures.<\/td>\n<\/tr>\n
UUID<\/td>\nUUID column<\/td>\nIdentify values that may need to be recorded in crypttab, fstab, or the inventory.<\/td>\n<\/tr>\n
Mount state<\/td>\nMOUNTPOINTS column<\/td>\nStop if the device is mounted or otherwise active.<\/td>\n<\/tr>\n
Layer structure<\/td>\nTree layout<\/td>\nDetermine whether the visible object is a physical disk, partition, LUKS container, mapper device, LVM member, logical volume, or filesystem.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The second inspection point is \/dev\/disk\/by-id. This directory exposes links based on device model names, serial numbers, and connection paths. When several external disks have similar sizes, capacity alone is not enough. The by-id name is not perfect in every hardware configuration, but it is much closer to physical identity than \/dev\/sdX. Use it to connect the temporary working name to a real device.<\/p>\n

1
<\/div><\/td>
ls -l \/dev\/disk\/by-id\/<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The output shows symlinks pointing to devices such as ..\/..\/sdb or ..\/..\/sdb1. This mapping allows the operator to confirm that the current \/dev\/sdX name corresponds to the intended physical disk. If the by-id name shows an unexpected model, serial number, or bridge device, stop the procedure. In encrypted disk work, target certainty is more important than command speed.<\/p>\n\n\n\n\n\n\n\n\n\n
Identifier<\/th>\nMeaning<\/th>\nHow to use it<\/th>\n<\/tr>\n<\/thead>\n
\/dev\/sdX<\/td>\nA temporary device name assigned by the current boot and attachment state.<\/td>\nUse only for immediate interactive work after confirmation.<\/td>\n<\/tr>\n
\/dev\/disk\/by-id<\/td>\nA more physical identifier derived from device model, serial, or path.<\/td>\nRecord it in the inventory to distinguish similar disks.<\/td>\n<\/tr>\n
LUKS UUID<\/td>\nThe identifier stored in the LUKS header.<\/td>\nUse it for crypttab and encrypted-device inventory.<\/td>\n<\/tr>\n
Filesystem UUID<\/td>\nThe identifier of the filesystem created after the LUKS device is opened.<\/td>\nUse it for fstab and mount-level inventory.<\/td>\n<\/tr>\n
Physical label<\/td>\nA human label attached to the actual disk or enclosure.<\/td>\nUse it as a practical cross-check when several media look similar.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The next step is allowed only when the operator can explain the target\u2019s capacity, physical device, current device name, partition boundary, existing filesystem, mount state, and intended role. If that cannot be explained, the procedure is not ready for luksFormat, mkfs, erase, or header restoration. When lsblk and by-id do not resolve the ambiguity, use blkid and fdisk -l as additional confirmation tools rather than proceeding by assumption.<\/p>\n

\n

3. Create a new LUKS2 device deliberately<\/h2>\n

For a new primary encrypted disk, LUKS2 is the natural explicit choice. The cryptsetup FAQ and LUKS specifications describe LUKS as a format with headers, key slots, and master-key management[8]<\/a>[9]<\/a>. LUKS2 adds a more extensible metadata structure and should be recorded as an intentional design decision when a new asset is created[10]<\/a>. The decision should be written down because future operators may otherwise be unable to tell whether a device is old by necessity, old by accident, or intentionally created for compatibility.<\/p>\n

The basic creation command is luksFormat. It is not an inspection command. It writes LUKS metadata to the target and changes how the target is interpreted. If the target contains old data, that data is no longer available through ordinary filesystem access after this operation. This command belongs only after the target has been identified and the operator has decided that the selected disk or partition may be initialized.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup luksFormat --type luks2 \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The placeholder \/dev\/sdX must be replaced with the confirmed disk or partition. If the whole disk is encrypted, the target might be a device such as \/dev\/sdb. If a partition is encrypted, the target might be \/dev\/sdb1. That choice is not cosmetic. It determines what remains visible outside the LUKS container, how partition tables are handled, and which identifier should be recorded for recovery.<\/p>\n

The first passphrase entered during luksFormat creates the initial opening path. This passphrase does not encrypt the data directly in the simple sense; it provides access to the LUKS-managed volume key through a key slot. Even if normal operation will later use a keyfile, retaining a strong emergency passphrase in a documented key slot is often valuable because it preserves a manual recovery route when keyfile or boot configuration fails.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup luksDump \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

After creation, luksDump verifies the LUKS header. The expected state is that Version is 2, a LUKS UUID is present, the data segment is defined, and at least one key slot is active. This initial state should be recorded before additional keyfiles, crypttab entries, fstab entries, or LVM layers are added.<\/p>\n\n\n\n\n\n\n\n\n\n
Item<\/th>\nExpected state<\/th>\nWhy it matters<\/th>\n<\/tr>\n<\/thead>\n
Version<\/td>\n2<\/td>\nConfirms that the device was created as LUKS2.<\/td>\n<\/tr>\n
UUID<\/td>\nA LUKS UUID is displayed.<\/td>\nIdentifies the encrypted device for inventory and crypttab.<\/td>\n<\/tr>\n
Data segments<\/td>\nA crypt segment is displayed.<\/td>\nShows that the encrypted data area is defined.<\/td>\n<\/tr>\n
Keyslots<\/td>\nAt least one active key slot exists.<\/td>\nConfirms that there is a valid opening path.<\/td>\n<\/tr>\n
PBKDF<\/td>\nArgon2id or another configured KDF is shown.<\/td>\nShows how passphrase-derived key material is produced.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

3.1 Design the first keyfile path carefully<\/h3>\n

A keyfile design should be decided early because it affects routine operation, crypttab, backup, and recovery. A keyfile path such as \/etc\/cryptsetup-keys\/crypt_name.key is only an example. In real operation, the name should identify the role of the encrypted device without encouraging reuse across unrelated devices. Reusing one keyfile for several volumes may be operationally convenient, but it expands the impact of keyfile leakage and makes replacement harder. A keyfile should be mapped to the LUKS UUID and role in the inventory.<\/p>\n

1
2
3
4
<\/div><\/td>
sudo mkdir -p \/etc\/cryptsetup-keys
\nsudo dd if=\/dev\/urandom of=\/etc\/cryptsetup-keys\/crypt_name.key bs=32 count=1
\nsudo chown root:root \/etc\/cryptsetup-keys\/crypt_name.key
\nsudo chmod 0400 \/etc\/cryptsetup-keys\/crypt_name.key<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

These commands create a 32-byte keyfile and restrict it to root. Existing keyfiles must never be overwritten casually. If a deployed keyfile is replaced, every LUKS device depending on that exact file may become unopenable by the automated path. The contents of the keyfile should not be displayed. Instead, record its path, size, owner, mode, checksum, associated LUKS UUID, associated key slot, and creation date.<\/p>\n

1
2
<\/div><\/td>
sudo wc -c \/etc\/cryptsetup-keys\/crypt_name.key
\nsudo sha256sum \/etc\/cryptsetup-keys\/crypt_name.key<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The checksum is an identifier for later comparison, not a replacement for the keyfile. It proves that the file being used in the future is the same file that was recorded earlier. It does not allow the keyfile to be reconstructed. Store the checksum in the inventory, not as a substitute for preserving the actual keyfile.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup luksAddKey \/dev\/sdX \/etc\/cryptsetup-keys\/crypt_name.key
\nsudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX
\nsudo cryptsetup luksDump \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

After adding the keyfile, open –test-passphrase verifies that the file actually unlocks the device without creating a mapper device. The final luksDump confirms that another active key slot exists. The inventory must record which slot belongs to the keyfile and which slot belongs to the emergency passphrase, because LUKS metadata alone does not preserve the operational reason for each slot.<\/p>\n

\n

4. Create the filesystem only after opening the LUKS device<\/h2>\n

After luksFormat, the physical device is a LUKS container, not a directly mountable filesystem. The encrypted block device must first be opened into a mapper device. The cryptsetup-open manual describes this action as creating a device mapping for the encrypted device[11]<\/a>. The mapper name becomes the operational object used by mkfs, mount, fstab, scripts, and recovery notes, so it should be stable and meaningful.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is \/dev\/mapper\/crypt_name. This operation opens the encrypted layer. It does not create a filesystem and it does not mount anything. If the keyfile is not used, omit the –key-file option and enter the passphrase interactively. The result is still the same kind of mapper device.<\/p>\n

Only after the mapper exists should the filesystem be created. mke2fs creates ext-family filesystems[12]<\/a>. It is not an encryption command. It must be pointed at the unlocked mapper device, not at the underlying LUKS device.<\/p>\n

1
<\/div><\/td>
sudo mkfs.ext4 \/dev\/mapper\/crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

This command is an initialization operation. It should be run once when creating a new filesystem. It should not appear in routine operation. If mkfs.ext4 is accidentally run against the underlying \/dev\/sdX target, it can damage or overwrite the LUKS container. If it is run against an existing mapper device during routine use, it recreates the filesystem and destroys the existing file hierarchy.<\/p>\n

1
2
<\/div><\/td>
sudo mkdir -p \/mnt\/crypt_name
\nsudo mount \/dev\/mapper\/crypt_name \/mnt\/crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The mkdir command creates the mount point, and mount attaches the newly created ext4 filesystem to the directory tree. At this stage, perform a simple write and read test, then close the device cleanly. Creation is not complete until the device has been opened, mounted, used minimally, unmounted, closed, reopened, and mounted again. That final repetition proves that the procedure is reproducible rather than only successful in a single transient shell session.<\/p>\n\n\n\n\n\n\n\n\n\n
Step<\/th>\nTarget<\/th>\nExpected result<\/th>\n<\/tr>\n<\/thead>\n
open<\/td>\nLUKS device<\/td>\n\/dev\/mapper\/crypt_name appears.<\/td>\n<\/tr>\n
mkfs.ext4<\/td>\nMapper device<\/td>\nAn ext4 filesystem exists inside the opened LUKS container.<\/td>\n<\/tr>\n
mkdir<\/td>\nDirectory path<\/td>\nThe mount point exists.<\/td>\n<\/tr>\n
mount<\/td>\nMapper device and mount point<\/td>\nFiles can be read and written through the mount point.<\/td>\n<\/tr>\n
close and reopen<\/td>\nMapper and LUKS device<\/td>\nThe opening procedure works after the initial session ends.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

5. Use a fixed routine sequence: open, mount, sync, umount, close<\/h2>\n

Routine operation uses an already-created LUKS device and an already-created filesystem. The correct mental model is layered. open unlocks the encrypted block device and creates a mapper device. mount attaches the filesystem on that mapper device to the directory tree. sync flushes pending writes. umount detaches the filesystem. close removes the mapper device. The close action is separate from filesystem unmounting[13]<\/a>.<\/p>\n

1
2
3
4
5
<\/div><\/td>
sudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name
\nsudo mount \/dev\/mapper\/crypt_name \/mnt\/crypt_name
\nsync
\nsudo umount \/mnt\/crypt_name
\nsudo cryptsetup close crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

If open succeeds but mount fails, the LUKS opening path likely worked and the problem is probably in the filesystem, mount point, device state, or configuration. If open fails, investigate the device identity, LUKS header, keyfile, passphrase, or key slot. This separation is essential during recovery. Treating every failure as an encryption failure makes diagnosis worse; treating every failure as a filesystem failure can lead to unsafe repair attempts before the encrypted layer is understood.<\/p>\n\n\n\n\n\n\n\n\n\n
Step<\/th>\nLayer<\/th>\nPurpose<\/th>\nFailure interpretation<\/th>\n<\/tr>\n<\/thead>\n
open<\/td>\nLUKS<\/td>\nCreate \/dev\/mapper\/crypt_name from the encrypted device.<\/td>\nFailure points to target identity, header, keyfile, passphrase, or key slot.<\/td>\n<\/tr>\n
mount<\/td>\nFilesystem<\/td>\nAttach the existing filesystem to a mount point.<\/td>\nFailure after successful open points to filesystem, mount point, or mount options.<\/td>\n<\/tr>\n
sync<\/td>\nKernel writeback<\/td>\nFlush pending writes before disconnecting.<\/td>\nFailure or delay may indicate I\/O trouble that should be recorded.<\/td>\n<\/tr>\n
umount<\/td>\nFilesystem<\/td>\nDetach the filesystem cleanly.<\/td>\nFailure often means a process is still using the mount point.<\/td>\n<\/tr>\n
close<\/td>\nMapper<\/td>\nRemove the unlocked mapping.<\/td>\nFailure usually means the mapper is still in use.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The important prohibition is simple: do not run mkfs.ext4 during routine use. Routine use opens and mounts an existing filesystem. It does not recreate it. Keeping creation and routine operation separate is one of the strongest protections against accidental data destruction.<\/p>\n

\n

6. Inspect the right layer for the question being asked<\/h2>\n

Encrypted disk inspection should be purpose-driven. If the question is whether a target is a LUKS device, use isLuks. If the question is what the LUKS header contains, use luksDump. If the question is whether the mapper is active, use status. If the question is how the physical device, mapper, filesystem, and mount point relate, use lsblk. If the question is which UUID belongs to which layer, use blkid. The lsblk and blkid manuals are especially relevant for separating hierarchy from identifiers[14]<\/a>[15]<\/a>.<\/p>\n

6.1 Confirm whether the target is a LUKS device<\/h3>\n

The first question in status inspection is whether the selected target is actually a LUKS device. This check should be performed before opening the device, changing key slots, backing up the header, or attempting recovery. It prevents the operator from running LUKS-specific operations against an ordinary filesystem, the wrong partition, or an unrecognized device.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup isLuks \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

isLuks is a yes-or-no test. It does not produce a rich inventory by itself. A successful exit indicates that the target is recognized as a LUKS device. Failure means the target may not be LUKS, the wrong disk or partition may have been selected, or the header may be damaged. Do not proceed to key-slot editing or header restore while this basic identity question is unresolved.<\/p>\n

6.2 Inspect the LUKS header and key slots<\/h3>\n

After confirming that the target is a LUKS device, inspect the header. This step is not decorative output. It identifies the LUKS version, UUID, cipher, KDF, data segment, and active key slots, and it gives the baseline for deciding whether key management, header backup, or recovery work can proceed safely.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup luksDump \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that LUKS header information is displayed and that the LUKS UUID, version, cipher, and active key slots can be compared with the inventory. For LUKS1, key slots appear as enabled or disabled entries. For LUKS2, key slots, tokens, and digests are shown in a more structured form. The operational question is not whether every low-level field is memorized, but whether the device is the expected encrypted asset and whether the active opening paths are known.<\/p>\n\n\n\n\n\n\n\n\n\n
Header item<\/th>\nWhere to look<\/th>\nOperational decision<\/th>\n<\/tr>\n<\/thead>\n
Version<\/td>\nVersion line<\/td>\nConfirms whether the asset is LUKS1 or LUKS2.<\/td>\n<\/tr>\n
LUKS UUID<\/td>\nUUID line<\/td>\nMust match the encrypted-device inventory and crypttab entry.<\/td>\n<\/tr>\n
Cipher and mode<\/td>\nCipher, cipher mode, or data segment fields<\/td>\nShows the storage encryption construction in use.<\/td>\n<\/tr>\n
Key slots<\/td>\nKey Slot or Keyslots section<\/td>\nShows how many opening paths exist and whether they are expected.<\/td>\n<\/tr>\n
KDF<\/td>\nPBKDF, iterations, memory, or threads<\/td>\nShows how passphrase or key material is processed.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Use luksDump after adding a key slot, before removing a key slot, before taking a header backup, after restoring metadata, and when investigating a migration source. In particular, never run luksKillSlot based only on memory. Confirm that another tested opening path exists first.<\/p>\n

6.3 Check an active mapper device<\/h3>\n

Once the encrypted device has been opened, inspect the mapper rather than the original block device. The mapper state answers a different question from the LUKS header: it tells whether an unlocked device currently exists, which source backs it, and whether later mount failures are occurring above or below the encryption layer.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup status crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

status applies to an opened mapper name, not to a raw disk path. The expected result is that the mapper is active and linked to the intended source device. If status cannot find the mapper, the device is not open. If the mapper is active but mounting fails, the failure is likely above the encryption layer.<\/p>\n

6.4 Inspect the physical-to-mounted hierarchy<\/h3>\n

Layer inspection should connect the physical disk, the encrypted container, the mapper, the filesystem, and the mount point. This is the quickest way to detect whether the operator is looking at the source device, the unlocked device, or a mounted filesystem.<\/p>\n

1
<\/div><\/td>
lsblk -f<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

lsblk -f is useful before opening, after opening, after mounting, and after closing. The expected hierarchy changes at each step. Before opening, only the physical crypto_LUKS layer may be visible. After opening, the mapper appears. After mounting, the filesystem and mount point appear. After closing, the mapper disappears. This sequence is a simple way to confirm that each layer has been entered and exited correctly.<\/p>\n

6.5 Distinguish LUKS UUID from filesystem UUID<\/h3>\n

UUID inspection must be layer-aware. The UUID attached to TYPE=”crypto_LUKS” identifies the encrypted container, while the UUID attached to the filesystem inside \/dev\/mapper identifies the mountable filesystem. Mixing these two values is a common cause of crypttab and fstab failures.<\/p>\n

1
<\/div><\/td>
sudo blkid<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

blkid is useful when transferring identifiers into configuration files. TYPE=”crypto_LUKS” belongs to the encrypted container. TYPE=”ext4″ on \/dev\/mapper\/crypt_name belongs to the filesystem after the device has been opened. crypttab usually identifies the encrypted container. fstab usually identifies the filesystem. These UUIDs must be recorded separately because they answer different questions.<\/p>\n\n\n\n\n\n\n\n\n\n
Question<\/th>\nCommand<\/th>\nExpected answer<\/th>\n<\/tr>\n<\/thead>\n
Is this a LUKS device?<\/td>\ncryptsetup isLuks<\/td>\nThe command exits successfully for a valid LUKS target.<\/td>\n<\/tr>\n
What header and key slots exist?<\/td>\ncryptsetup luksDump<\/td>\nLUKS version, UUID, cipher, KDF, and key slots are shown.<\/td>\n<\/tr>\n
Is the mapper open?<\/td>\ncryptsetup status<\/td>\nThe mapper is active and linked to the source device.<\/td>\n<\/tr>\n
How are layers connected?<\/td>\nlsblk -f<\/td>\nPhysical device, crypto layer, mapper, filesystem, and mount point are visible.<\/td>\n<\/tr>\n
Which UUID belongs to which layer?<\/td>\nblkid<\/td>\nTYPE=”crypto_LUKS” and filesystem UUIDs can be distinguished.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

7. Manage key slots as opening paths, not as data copies<\/h2>\n

A LUKS key slot is an opening path to the same encrypted volume key. It is not a second copy of the data. Adding a key slot adds another way to unlock the same encrypted device. Removing a key slot removes one opening path. Deleting the last working key slot makes the encrypted data practically unrecoverable even if the storage media is physically intact.<\/p>\n

The usual design is to keep at least two intentional opening paths: a normal keyfile for routine operation and a strong emergency passphrase for manual recovery. During administrator turnover or migration, a temporary opening path may be added, tested, used, and then removed. What should not remain is a set of undocumented old passphrases whose owners, purpose, and risk are unknown.<\/p>\n\n\n\n\n\n\n\n\n\n
Purpose<\/th>\nKey slot use<\/th>\nOperational meaning<\/th>\n<\/tr>\n<\/thead>\n
Routine operation<\/td>\nRegister a keyfile in a known slot.<\/td>\nAllow normal scripted or boot-time opening without interactive entry.<\/td>\n<\/tr>\n
Emergency recovery<\/td>\nRegister a strong passphrase in another known slot.<\/td>\nPreserve manual access when keyfile, boot, or crypttab configuration fails.<\/td>\n<\/tr>\n
Administrator turnover<\/td>\nAdd a new opening path, test it, then remove the old path.<\/td>\nRemove dependence on old credentials while preserving continuity.<\/td>\n<\/tr>\n
Migration<\/td>\nAdd a temporary path only for the migration window.<\/td>\nSupport controlled transfer, then reduce access paths again.<\/td>\n<\/tr>\n
Cleanup<\/td>\nRemove undocumented or obsolete slots after testing alternatives.<\/td>\nPrevent old unknown credentials from remaining valid indefinitely.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

8. Add key slots and test the new opening path<\/h2>\n

Adding a key slot is safer than removing one, but it is still an operational change. luksAddKey requires an already valid opening path and adds another opening path. The new path must be tested immediately; otherwise the inventory may claim that a recovery route exists when it does not.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup luksAddKey \/dev\/sdX \/etc\/cryptsetup-keys\/crypt_name.key
\nsudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX
\nsudo cryptsetup luksDump \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

When adding an emergency passphrase while authenticating with an existing keyfile, the command structure is different. The keyfile is used as the old valid opening path, while the new passphrase is entered interactively and stored in a new slot.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup luksAddKey \/dev\/sdX --key-file \/etc\/cryptsetup-keys\/crypt_name.key
\nsudo cryptsetup open --test-passphrase \/dev\/sdX
\nsudo cryptsetup luksDump \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

After the operation, record which slot corresponds to the keyfile and which slot corresponds to the emergency passphrase. If the slot number is not documented at the time of creation, later cleanup becomes guesswork. A valid inventory entry includes the LUKS UUID, slot number, opening method, purpose, creation date, latest test date, and planned removal date if the slot is temporary.<\/p>\n\n\n\n\n\n\n\n\n
After adding a key<\/th>\nRequired verification<\/th>\nReason<\/th>\n<\/tr>\n<\/thead>\n
Keyfile slot added<\/td>\nRun open –test-passphrase with –key-file.<\/td>\nConfirms that the exact file can open the device.<\/td>\n<\/tr>\n
Emergency passphrase added<\/td>\nRun open –test-passphrase interactively.<\/td>\nConfirms that a human recovery path exists.<\/td>\n<\/tr>\n
Slot count changed<\/td>\nRun luksDump and compare with inventory.<\/td>\nConfirms that the expected slot state exists.<\/td>\n<\/tr>\n
Temporary migration slot added<\/td>\nRecord the deletion condition immediately.<\/td>\nPrevents temporary access from becoming permanent by neglect.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

9. Inspect and remove unnecessary key slots carefully<\/h2>\n

Removing an opening path requires more care than adding one. luksRemoveKey removes the slot corresponding to supplied passphrase or key material[16]<\/a>. luksKillSlot removes a specific slot number. The second form is useful only when the inventory and luksDump output are understood. Before removing any slot, verify that another known path can open the device.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup luksDump \/dev\/sdX
\nsudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX
\nsudo cryptsetup open --test-passphrase \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The precondition for removal is not merely that another slot exists. It is that another known, documented, tested opening path exists. If the only tested path is the one being removed, the operation is unsafe. If the inventory does not say which slot is which, stop and reconstruct the meaning of the slots before deletion.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup luksRemoveKey \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

luksRemoveKey removes the slot matching the supplied key material. This is often safer than killing a slot by number when the operator wants to remove a known passphrase or keyfile. It still requires caution because the command changes the set of valid opening paths.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup luksKillSlot \/dev\/sdX 1<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

luksKillSlot removes the specified slot number. Use it only when luksDump and the inventory agree that the slot number is the intended obsolete path. After removal, run luksDump again and test the remaining routine and emergency paths. The final state should have no undocumented active slots and at least one, preferably two, tested intentional opening paths.<\/p>\n\n\n\n\n\n\n\n
Removal method<\/th>\nAppropriate use<\/th>\nMain risk<\/th>\n<\/tr>\n<\/thead>\n
luksRemoveKey<\/td>\nRemove a known passphrase or keyfile by presenting that material.<\/td>\nThe supplied material may correspond to a path still needed elsewhere.<\/td>\n<\/tr>\n
luksKillSlot<\/td>\nRemove a specific slot after inventory confirmation.<\/td>\nThe operator may kill the wrong slot by number.<\/td>\n<\/tr>\n
cryptsetup erase<\/td>\nDestroy all LUKS key material during retirement.<\/td>\nThe data becomes unrecoverable if no independent copy exists.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

10. Back up, store, verify, and restore LUKS headers as metadata<\/h2>\n

The LUKS header is not an optional label. It contains the metadata required to interpret and unlock the encrypted data. If the data area remains intact but the header becomes unusable, the disk may no longer be openable. Header backup is therefore part of encrypted disk operation, but it must be treated with precision. A header backup belongs to a specific device state. Restoring the wrong header to the wrong device can make recovery worse.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup luksHeaderBackup \/dev\/sdX --header-backup-file luks-header-crypt_name-YYYYMMDD.img
\nsudo cryptsetup luksDump \/dev\/sdX
\nsha256sum luks-header-crypt_name-YYYYMMDD.img<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

A useful header backup record includes the target by-id name, LUKS UUID, backup date, backup filename, checksum, LUKS version, active key slots at the time of backup, and where the file is stored. Header backups should not be stored only inside the encrypted volume they are meant to recover. They should also not be mixed without labels across multiple similar disks.<\/p>\n\n\n\n\n\n\n\n\n\n
Header backup record<\/th>\nRequired value<\/th>\nRecovery use<\/th>\n<\/tr>\n<\/thead>\n
Device identity<\/td>\nby-id path, physical label, and role.<\/td>\nPrevents restoring a header to the wrong disk.<\/td>\n<\/tr>\n
LUKS UUID<\/td>\nUUID shown by luksDump.<\/td>\nMatches backup metadata to the encrypted container.<\/td>\n<\/tr>\n
Backup file<\/td>\nFilename and storage location.<\/td>\nAllows the backup to be found without opening the damaged volume.<\/td>\n<\/tr>\n
Checksum<\/td>\nsha256sum or equivalent.<\/td>\nDetects accidental modification or wrong-file selection.<\/td>\n<\/tr>\n
Slot state<\/td>\nActive key slots at backup time.<\/td>\nShows whether restoring this header would revert later key-slot changes.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
1
<\/div><\/td>
sudo cryptsetup luksHeaderRestore \/dev\/sdX --header-backup-file luks-header-crypt_name-YYYYMMDD.img<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Header restoration is a last-resort recovery action, not routine maintenance. Before using it, confirm the target device identity, confirm that the backup matches the LUKS UUID and operational record, prefer read-only rescue if possible, and understand that restoring stale metadata may invalidate newer key-slot changes. Header backup is valuable because it preserves a recovery path; header restore is dangerous because it writes metadata back to the encrypted device.<\/p>\n

\n

11. Separate automatic unlocking from automatic mounting<\/h2>\n

Automatic boot configuration has two distinct stages. crypttab describes how encrypted devices are opened. fstab describes how filesystems are mounted after the required device exists. systemd\u2019s crypttab handling and generator turn crypttab entries into cryptsetup units at boot[17]<\/a>[18]<\/a>. The fstab and systemd.mount documentation describe the mount layer[19]<\/a>[20]<\/a>. Mixing these layers produces brittle boot failures.<\/p>\n

11.1 Inspect current automatic configuration<\/h3>\n

Before changing automatic startup configuration, first inspect the current crypttab, fstab, mapper devices, and block-device hierarchy. The purpose is not merely to read what the configuration files contain. The purpose is to verify whether configuration and reality match. Check whether the mapper name declared in crypttab actually appears under \/dev\/mapper, whether the mount point declared in fstab is actually mounted, and whether the hierarchy shown by lsblk -f matches the intended layer structure.<\/p>\n

1
2
3
4
<\/div><\/td>
cat \/etc\/crypttab
\ncat \/etc\/fstab
\nls -l \/dev\/mapper\/
\nlsblk -f<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that the mapper name defined in crypttab exists under \/dev\/mapper and that the mount point defined in fstab appears in the MOUNTPOINTS column of lsblk -f. If the mapper does not exist, the encrypted device may not have been unlocked. If the mapper exists but the filesystem is not mounted, the more likely problem is in fstab, mount options, the filesystem, or the mount point. This distinction separates a boot problem into \u201cLUKS did not open\u201d and \u201cthe filesystem did not mount after LUKS opened.\u201d<\/p>\n\n\n\n\n\n\n\n\n
Inspection target<\/th>\nWhere to look<\/th>\nWhat it tells you<\/th>\n<\/tr>\n<\/thead>\n
crypttab<\/td>\nRead \/etc\/crypttab.<\/td>\nShows which encrypted device should be opened, under which mapper name, and by which keyfile or unlocking method.<\/td>\n<\/tr>\n
fstab<\/td>\nRead \/etc\/fstab.<\/td>\nShows where the decrypted filesystem should be mounted after the mapper exists.<\/td>\n<\/tr>\n
mapper<\/td>\nInspect \/dev\/mapper.<\/td>\nShows whether the mapper device that crypttab should create actually exists.<\/td>\n<\/tr>\n
Device hierarchy<\/td>\nInspect lsblk -f.<\/td>\nShows the relationship among the physical device, LUKS layer, mapper device, filesystem, and mount point.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The operational point is that automatic startup must be verified as a chain, not as isolated configuration files. crypttab is meaningful only if it creates the intended mapper device. fstab is meaningful only if the filesystem exposed through that mapper is mounted at the intended mount point. lsblk -f connects these declarations to the current device reality.<\/p>\n

11.2 crypttab opens encrypted devices<\/h3>\n

crypttab defines how encrypted devices are opened. In this layer, the system is not yet mounting the filesystem. It is identifying a LUKS device, choosing a mapper name, and selecting the key material or unlocking method. The UUID used here should be the LUKS UUID stored in the encrypted container header, not the filesystem UUID that appears after the device is opened.<\/p>\n

1
<\/div><\/td>
crypt_name UUID=LUKS-UUID \/etc\/cryptsetup-keys\/crypt_name.key luks<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The first field is the mapper name that should appear as \/dev\/mapper\/crypt_name. The second field identifies the encrypted source device, commonly by LUKS UUID. The third field identifies the keyfile or declares another unlocking method. The fourth field contains crypttab options. The expected result is that boot-time processing creates the mapper device using the declared key material.<\/p>\n\n\n\n\n\n\n\n\n
Field<\/th>\nRole<\/th>\nCommon mistake<\/th>\n<\/tr>\n<\/thead>\n
Mapper name<\/td>\nDefines the name under \/dev\/mapper.<\/td>\nUsing a name that does not match fstab, scripts, or the inventory.<\/td>\n<\/tr>\n
Source device<\/td>\nIdentifies the encrypted LUKS device.<\/td>\nUsing the filesystem UUID instead of the LUKS UUID.<\/td>\n<\/tr>\n
Key material<\/td>\nSpecifies the keyfile or unlocking source.<\/td>\nPointing to a file that is not readable during boot.<\/td>\n<\/tr>\n
Options<\/td>\nControls cryptsetup and systemd behavior.<\/td>\nAdding timeouts or dependencies without first fixing the identity chain.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The inventory should record the crypttab line as an opening rule: source LUKS UUID, mapper name, keyfile path, keyfile permissions, and boot-time availability. If automatic unlocking fails, this is the layer to inspect before looking at fstab.<\/p>\n

11.3 fstab mounts filesystems<\/h3>\n

fstab defines how filesystems are mounted after the required block device exists. In a LUKS setup, the fstab entry normally refers to the filesystem exposed through \/dev\/mapper\/crypt_name, not to the encrypted physical device itself. The UUID here is therefore usually the filesystem UUID, not the LUKS UUID. This distinction is central to troubleshooting automatic startup.<\/p>\n

1
<\/div><\/td>
UUID=FILESYSTEM-UUID \/mnt\/crypt_name ext4 defaults 0 2<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The first field identifies the filesystem. The second field gives the mount point. The third field gives the filesystem type. The fourth field gives mount options. The final fields control dump and fsck order. The expected result is that, after crypttab has created the mapper device, the filesystem is mounted at the declared mount point.<\/p>\n\n\n\n\n\n\n\n\n
Field<\/th>\nRole<\/th>\nCommon mistake<\/th>\n<\/tr>\n<\/thead>\n
Filesystem identifier<\/td>\nIdentifies the filesystem visible after unlocking.<\/td>\nUsing the LUKS UUID instead of the filesystem UUID.<\/td>\n<\/tr>\n
Mount point<\/td>\nDefines where the filesystem should appear.<\/td>\nReferencing a directory that does not exist or is already used for another purpose.<\/td>\n<\/tr>\n
Filesystem type<\/td>\nDeclares ext4, xfs, vfat, or another type.<\/td>\nAssuming the type without checking lsblk -f or blkid.<\/td>\n<\/tr>\n
Mount options<\/td>\nControls mount behavior and error handling.<\/td>\nUsing options that hide failures or block boot unintentionally.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

If the mapper exists but the mount point is empty, fstab is the next layer to inspect. If the mapper does not exist, fstab cannot solve the problem because the filesystem device has not yet appeared. This is why crypttab and fstab must be documented separately even when they describe one operational asset.<\/p>\n

11.4 Diagnose automatic startup failures by layer<\/h3>\n

Automatic startup failures should be diagnosed by layer rather than treated as a single boot problem. First determine whether the encrypted device was discovered, whether the LUKS device was unlocked, whether the mapper device was created, whether the filesystem was recognized, whether the mount operation ran, whether permissions or keyfile visibility failed, and whether systemd dependencies delayed or blocked the process. If \/dev\/mapper\/crypt_name does not exist, the problem is usually before the filesystem layer: crypttab, the keyfile, the LUKS UUID, device discovery, or the systemd-cryptsetup stage. If \/dev\/mapper\/crypt_name exists but the filesystem is not mounted, the problem has usually moved to fstab, the mount point, the filesystem UUID, mount options, or filesystem health. lsblk -f is the quickest way to see this boundary because it shows the physical device, crypto layer, mapper, filesystem, and mount point in one hierarchy.<\/p>\n\n\n\n\n\n\n\n\n
Failure point<\/th>\nLikely layer<\/th>\nFirst checks<\/th>\n<\/tr>\n<\/thead>\n
The mapper is not created<\/td>\ncrypttab, keyfile, LUKS UUID, systemd-cryptsetup, device discovery<\/td>\nCheck the LUKS UUID, keyfile path, keyfile permissions, mapper name, systemd-cryptsetup unit, and lsblk output.<\/td>\n<\/tr>\n
The mapper exists but is not mounted<\/td>\nfstab, mount point, filesystem UUID, mount options, filesystem state<\/td>\nCheck the fstab entry, mount point existence, filesystem UUID, mount options, and e2fsck status.<\/td>\n<\/tr>\n
Boot waits too long<\/td>\ncrypttab options, fstab options, systemd dependencies, device timeout<\/td>\nCheck whether the target device is absent, whether the external disk is disconnected, and whether timeout or nofail policy is appropriate.<\/td>\n<\/tr>\n
Manual open works but automatic unlock fails<\/td>\nkeyfile visibility, permissions, initramfs, systemd boot context<\/td>\nCheck whether the keyfile path is readable at the stage where crypttab is processed, not merely after the system is fully booted.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The operational point is that automatic startup is not just \u201cwrite crypttab\u201d plus \u201cwrite fstab.\u201d crypttab opens the encrypted device, fstab mounts the filesystem exposed after that device exists, and systemd generates boot-time units from those declarations and their dependencies. A reliable inventory must therefore record the LUKS UUID, mapper name, keyfile path, filesystem UUID, mount point, keyfile availability during boot, and the diagnostic boundary between unlock failure and mount failure.<\/p>\n

\n

12. Document the LUKS and LVM layer order<\/h2>\n

LUKS and LVM can be combined in more than one order. The device-mapper and LVM documentation are necessary background because both LUKS and LVM are mapper-based layers[21]<\/a>[22]<\/a>. The procedure must record which layer is above the other. Recovery order depends on this design.<\/p>\n

12.1 LVM on LUKS<\/h3>\n

In the LVM-on-LUKS design, the physical device or partition contains the LUKS container. After the LUKS device is opened, the resulting mapper device becomes the LVM physical volume. The volume group and logical volumes exist inside the encrypted layer. This design is common when the intention is to encrypt all logical volumes below one encrypted boundary.<\/p>\n

1
2
3
4
5
<\/div><\/td>
sudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name
\nsudo pvscan
\nsudo vgscan
\nsudo vgchange -ay
\nsudo lvs<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that LUKS opens first, then LVM sees a physical volume through \/dev\/mapper\/crypt_name, then the volume group can be activated, and finally logical volumes become visible. If LUKS is not opened, LVM will not see the encrypted physical volume. Therefore, recovery begins with the LUKS layer.<\/p>\n\n\n\n\n\n\n\n\n
Step<\/th>\nLayer reached<\/th>\nFailure implication<\/th>\n<\/tr>\n<\/thead>\n
cryptsetup open<\/td>\nCreates the decrypted mapper device.<\/td>\nIf this fails, inspect LUKS UUID, key material, key slot, and header state.<\/td>\n<\/tr>\n
pvscan \/ vgscan<\/td>\nDiscovers LVM metadata inside the mapper.<\/td>\nIf this fails after LUKS opens, inspect LVM metadata and the selected mapper device.<\/td>\n<\/tr>\n
vgchange -ay<\/td>\nActivates the volume group.<\/td>\nIf this fails, inspect VG state rather than the LUKS passphrase.<\/td>\n<\/tr>\n
lvs<\/td>\nLists logical volumes.<\/td>\nIf logical volumes are missing, the problem is now in LVM or inventory mismatch.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The inventory should record this as \u201cphysical device \u2192 LUKS \u2192 mapper \u2192 PV\/VG\/LV \u2192 filesystem.\u201d Without that order, a later operator may try to activate LVM before opening the encrypted boundary and misdiagnose a normal hidden layer as missing data.<\/p>\n

12.2 LUKS on LVM<\/h3>\n

In the LUKS-on-LVM design, LVM is activated first, and one or more logical volumes are encrypted individually. This design can be useful when different logical volumes require different keys, policies, or retirement schedules. The recovery order is different from LVM on LUKS: the volume group must be visible first, then the encrypted logical volume can be opened.<\/p>\n

1
2
3
4
5
<\/div><\/td>
sudo pvscan
\nsudo vgscan
\nsudo vgchange -ay
\nsudo lvs
\nsudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/vg_name\/lv_name crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that LVM sees and activates the volume group before cryptsetup opens the encrypted logical volume. If the volume group cannot be activated, cryptsetup will not find \/dev\/vg_name\/lv_name as a usable encrypted target. If the logical volume is visible but cryptsetup cannot open it, the problem has moved to the LUKS layer inside LVM.<\/p>\n\n\n\n\n\n\n\n\n
Step<\/th>\nLayer reached<\/th>\nFailure implication<\/th>\n<\/tr>\n<\/thead>\n
pvscan \/ vgscan<\/td>\nDiscovers LVM metadata on the physical device.<\/td>\nIf this fails, inspect physical disks and LVM metadata before inspecting LUKS.<\/td>\n<\/tr>\n
vgchange -ay<\/td>\nActivates the volume group.<\/td>\nIf this fails, the encrypted logical volume may not exist as a visible device yet.<\/td>\n<\/tr>\n
lvs<\/td>\nIdentifies the encrypted logical volume.<\/td>\nIf the LV name differs from the inventory, stop and resolve the mismatch.<\/td>\n<\/tr>\n
cryptsetup open<\/td>\nOpens LUKS inside the logical volume.<\/td>\nIf this fails, inspect LUKS UUID, key material, key slot, and header state.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The inventory should record this as \u201cphysical device \u2192 PV\/VG\/LV \u2192 LUKS \u2192 mapper \u2192 filesystem.\u201d The same commands appear in both LVM designs, but the safe order is not the same. That order is part of the recovery procedure.<\/p>\n

12.3 Compare the two patterns<\/h3>\n

The two LUKS and LVM patterns should be compared by recovery order, not by appearance. Both eventually expose a filesystem through mapper devices, but the first command needed during recovery is different. In LVM on LUKS, the encrypted boundary must be opened before the volume group can be activated. In LUKS on LVM, the volume group must be visible first because the encrypted container lives inside a logical volume. The table summarizes the operational difference that must be preserved in the inventory.<\/p>\n\n\n\n\n\n\n
Design<\/th>\nLayer order<\/th>\nOperational consequence<\/th>\n<\/tr>\n<\/thead>\n
LVM on LUKS<\/td>\nPhysical device \u2192 LUKS \u2192 mapper \u2192 PV\/VG\/LV \u2192 filesystem<\/td>\nOpen LUKS first, then activate LVM volumes.<\/td>\n<\/tr>\n
LUKS on LVM<\/td>\nPhysical device \u2192 PV\/VG\/LV \u2192 LUKS \u2192 mapper \u2192 filesystem<\/td>\nActivate LVM first, then open each encrypted logical volume.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The consequence is practical. A recovery procedure that activates LVM before opening LUKS may be correct for one design and wrong for the other. The inventory should therefore record the physical device, PV, VG, LV, LUKS UUID, mapper name, filesystem UUID, and mount point as a single ordered stack. The purpose is not to document every internal detail of LVM, but to prevent the operator from guessing the layer order under pressure.<\/p>\n

12.4 Inspect both LUKS and LVM state<\/h3>\n

When LUKS and LVM are combined, status inspection must include both technologies. The point is not merely to confirm that LUKS and LVM both exist, but to determine which layer depends on the other and which command must run first during recovery.<\/p>\n

1
2
3
4
5
6
<\/div><\/td>
lsblk -f
\nsudo blkid
\nsudo cryptsetup status crypt_name
\nsudo pvs
\nsudo vgs
\nsudo lvs<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

During recovery, never guess whether LUKS is inside LVM or LVM is inside LUKS. Use lsblk -f, blkid, pvs, vgs, lvs, cryptsetup status, and the inventory to reconstruct the stack before attempting repair. The question is not merely whether both technologies are present. The question is which one must be activated first.<\/p>\n

12.5 Record the recovery sequence<\/h3>\n

The inventory should include the physical device, PV, VG, LV, LUKS UUID, mapper name, filesystem UUID, mount point, and exact recovery order. A layered configuration that is well recorded can be recovered systematically. A layered configuration that is not recorded becomes a puzzle at precisely the moment when mistakes are most expensive.<\/p>\n

\n

13. Inspect filesystems and storage media in stages<\/h2>\n

Filesystem checks and media checks answer different questions. e2fsck checks ext-family filesystem consistency and should normally be run on an unmounted filesystem[23]<\/a>. fsck is a frontend for filesystem-specific checkers[24]<\/a>. smartmontools provides SMART inspection for supported storage devices[25]<\/a>. None of these replaces the others.<\/p>\n

13.1 First confirm that the encrypted layer can be opened<\/h3>\n

Periodic inspection should start by testing the encrypted layer itself. A filesystem check is not meaningful if the intended LUKS opening path no longer works. This step confirms that the documented keyfile or passphrase can still reach the encrypted container.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX
\nsudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name
\nsudo cryptsetup status crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Before checking a filesystem, confirm that the encryption layer can be opened. If the encrypted layer cannot be opened, filesystem tools are not yet relevant. The failure is in device identity, LUKS metadata, keyfile, passphrase, or key slot.<\/p>\n

13.2 Run filesystem checks only while unmounted<\/h3>\n

Filesystem checks should be performed only after the encrypted device is opened and before the filesystem is mounted. This preserves the distinction between unlocking the block device and checking the consistency of the filesystem exposed through the mapper. Running repair-oriented checks on a mounted filesystem risks changing metadata under active use.<\/p>\n

1
2
<\/div><\/td>
sudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name
\nsudo e2fsck -f \/dev\/mapper\/crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that e2fsck inspects the ext-family filesystem visible through \/dev\/mapper\/crypt_name. If the filesystem is mounted, unmount it before checking. If the mapper cannot be created, the problem is below the filesystem layer and e2fsck is not yet the right tool.<\/p>\n\n\n\n\n\n\n\n\n
State<\/th>\nMeaning<\/th>\nNext action<\/th>\n<\/tr>\n<\/thead>\n
Mapper cannot be created<\/td>\nLUKS opening failed.<\/td>\nCheck keyfile, passphrase, key slots, header, and target identity.<\/td>\n<\/tr>\n
Mapper exists and filesystem is unmounted<\/td>\nFilesystem check can proceed.<\/td>\nRun e2fsck on \/dev\/mapper\/crypt_name.<\/td>\n<\/tr>\n
Filesystem is mounted<\/td>\nRepair check is unsafe.<\/td>\nUnmount first, or use read-only inspection if recovery is underway.<\/td>\n<\/tr>\n
e2fsck reports serious errors<\/td>\nFilesystem metadata may be damaged.<\/td>\nPrefer data rescue before repeated repair attempts.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The inspection result should record whether the check was clean, whether repairs were made, and whether the filesystem was mounted or unmounted at the time. That record matters later when distinguishing filesystem deterioration from media or LUKS failures.<\/p>\n

13.3 During recovery, prefer read-only mounting first<\/h3>\n

When inspection is being performed under uncertainty, especially during recovery, a read-only mount should come before any repair attempt. The goal is to learn whether data is readable without changing filesystem metadata.<\/p>\n

1
<\/div><\/td>
sudo mount -o ro \/dev\/mapper\/crypt_name \/mnt\/recovery<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

If the purpose is recovery rather than routine maintenance, prefer read-only mounting before repair. A read-only mount can allow data rescue without changing filesystem metadata. Repair may be necessary later, but repair should not be the first action when a readable copy may still be obtained.<\/p>\n

13.4 Read representative data, not only directory names<\/h3>\n

A successful mount does not prove that the data is meaningfully readable. Directory listings can succeed while important files are damaged, missing, or unreadable. Inspection should therefore include representative reads from important data areas.<\/p>\n

1
2
<\/div><\/td>
find \/mnt\/recovery -maxdepth 2 -type f | head
\nsha256sum \/mnt\/recovery\/path\/to\/important-file<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

A top-level directory listing proves very little. Read representative files, especially files that matter operationally. Check archives, large files, small files, and recently changed files if they are part of the protected data set. Readability is a stronger signal than mount success alone.<\/p>\n

13.5 Check physical media separately<\/h3>\n

Filesystem consistency and media health are different questions. A clean filesystem does not prove that the underlying disk is healthy, and worrying SMART attributes do not always mean the filesystem is already unreadable. Both signals should be recorded separately.<\/p>\n

1
<\/div><\/td>
sudo smartctl -a \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

SMART output describes media condition, not filesystem consistency. A filesystem can be clean on a device with warning signs, and a device with warning signs can remain readable for a limited rescue window. Record SMART results separately from e2fsck results because they drive different decisions: repair, migration, replacement, or retirement.<\/p>\n

13.6 Close the device after inspection<\/h3>\n

Inspection is incomplete until the mounted filesystem is unmounted and the mapper device is closed. Leaving a mapper active after inspection blurs the boundary between a controlled test and ongoing operation.<\/p>\n

1
2
3
4
<\/div><\/td>
sync
\nsudo umount \/mnt\/crypt_name
\nsudo cryptsetup close crypt_name
\nlsblk -f<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Inspection is not complete until the device is cleanly closed and the mapper is gone. Leaving a mapper device open after an inspection blurs the state of the system and can cause later scripts or operators to act on an unintended open device.<\/p>\n

13.7 Record the inspection result<\/h3>\n

An inspection that leaves no record has limited long-term value. The purpose of periodic inspection is not only to know that the device worked once, but to build a time series of unlockability, filesystem consistency, media condition, and close-state behavior. When the next failure occurs, these records distinguish a sudden incident from a slow deterioration pattern.<\/p>\n\n\n\n\n\n\n\n\n\n
Inspection item<\/th>\nRecord<\/th>\nDecision value<\/th>\n<\/tr>\n<\/thead>\n
Open test<\/td>\nDate, key path, passphrase test result, mapper name.<\/td>\nShows whether the opening path still works.<\/td>\n<\/tr>\n
Filesystem check<\/td>\nCommand, result, whether fixes were applied.<\/td>\nShows filesystem consistency and repair history.<\/td>\n<\/tr>\n
Read test<\/td>\nRepresentative paths and checksum results.<\/td>\nShows that important data can actually be read.<\/td>\n<\/tr>\n
SMART check<\/td>\nDevice, date, notable attributes, overall assessment.<\/td>\nSupports media replacement or retirement decisions.<\/td>\n<\/tr>\n
Close state<\/td>\nMapper removed and mount point inactive.<\/td>\nConfirms that inspection ended cleanly.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The record should be concise enough to maintain but specific enough to support decisions. A line saying \u201cchecked OK\u201d is weaker than a record that names the device, the LUKS UUID, the key path tested, the filesystem checker result, the SMART result, and whether the mapper was closed. The inspection result becomes part of the recovery evidence.<\/p>\n

\n

14. Inventory cryptographic configuration and decide migration by risk, not fashion<\/h2>\n

A cryptographic inventory should identify the cipher, mode, KDF, LUKS version, key-slot state, and operational role of each encrypted asset. AES is standardized in FIPS 197[26]<\/a>. NIST SP 800-38A describes classical block cipher modes such as CBC[27]<\/a>, while SP 800-38E describes XTS-AES for storage confidentiality[28]<\/a>. PBKDF2 is specified in RFC 8018[29]<\/a>, and Argon2 is specified in RFC 9106[30]<\/a>. NIST has also discussed updates to SP 800-38E[31]<\/a>, and its key-management and algorithm-transition guidance provide broader context for lifecycle decisions[32]<\/a>[33]<\/a>.<\/p>\n

The operational conclusion is not \u201cold means immediately unusable\u201d or \u201cnew means automatically worth migrating.\u201d A low-change archival disk, an actively updated backup disk, a server boot volume, and an obsolete compatibility volume have different risk profiles. Migration becomes more justified when the asset is actively written, exposed to operational change, dependent on aging media, poorly documented, configured with obsolete assumptions, or nearing a maintenance window where verification is feasible. Migration is less urgent when the asset is read-only, has multiple verified copies, is retained only for historical compatibility, and remains openable under controlled procedures.<\/p>\n\n\n\n\n\n\n\n\n\n
Factor<\/th>\nMigration pressure increases when<\/th>\nMigration pressure decreases when<\/th>\n<\/tr>\n<\/thead>\n
Write activity<\/td>\nThe volume is actively updated and exposed to repeated operational risk.<\/td>\nThe volume is read-only or rarely accessed.<\/td>\n<\/tr>\n
Documentation<\/td>\nOpening paths, headers, and layer order are unclear.<\/td>\nInventory and recovery procedures are current and tested.<\/td>\n<\/tr>\n
Media condition<\/td>\nSMART, age, performance, or error history indicates deterioration.<\/td>\nThe media has no warning signs and has verified alternate copies.<\/td>\n<\/tr>\n
Cryptographic generation<\/td>\nThe configuration uses obsolete assumptions and the asset remains important.<\/td>\nThe asset is retained only as a compatibility copy with limited exposure.<\/td>\n<\/tr>\n
Verification window<\/td>\nThere is time to create, sync, and verify a new target safely.<\/td>\nMigration would be rushed and less verifiable than continued controlled preservation.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This table should not be read as a rule that newer is always better. It is a decision framework. A migration that cannot be verified may reduce resilience even if the target format is newer. Conversely, a well-timed migration can reduce both cryptographic and operational risk when the old asset is active, underdocumented, or stored on deteriorating media.<\/p>\n

\n

15. Position existing TrueCrypt \/ TCRYPT assets as compatibility backups<\/h2>\n

cryptsetup can handle not only LUKS but also TrueCrypt \/ VeraCrypt style TCRYPT containers. Therefore, existing assets created with TrueCrypt 7.1a should not be treated simply as targets to migrate and delete because they are old. TrueCrypt is no longer maintained, so it should not be expanded as a new primary format. However, existing encrypted containers and encrypted disks may have meaning as compatibility backups for reaching past data. The important point is to classify existing TrueCrypt \/ TCRYPT assets clearly as current primary, compatibility backup, read-oriented archive, migration target, or retirement candidate.<\/p>\n

The TrueCrypt User Guide explains the TrueCrypt format and operation, but TrueCrypt is now discontinued[34]<\/a>. BSI’s TrueCrypt analysis and NCC Group’s Phase Two Audit are materials for calmly evaluating past assets, not guarantees of permanent use[35]<\/a>[36]<\/a>[37]<\/a>. Therefore, the decision should not be binary. It should be made by role. Primary storage that continues to receive ordinary updates should move toward LUKS2. On the other hand, there are rational reasons to keep existing TrueCrypt \/ TCRYPT assets for a period of time: compatibility with older environments, the readability of old FAT-based media, preservation of prior backup states, and an escape route when migration to LUKS + ext4 creates performance problems.<\/p>\n

The first task is to confirm whether the existing TCRYPT asset can still be opened, how it was created, and what data it contains. tcryptDump is used to inspect TCRYPT header information[38]<\/a>. This is not a data-changing operation. It is an investigation to confirm whether the target is recognized as TCRYPT. The expected result is that it is recognized as a TCRYPT container and that the cipher and header information can be inspected.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup tcryptDump \/path\/to\/container.tc<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Next, open the TCRYPT container as a mapper device. open –type tcrypt is the operation used by cryptsetup to open TrueCrypt \/ VeraCrypt style containers or devices. Here, \/path\/to\/container.tc is an example of a file container; in practice, a whole device or partition may also be specified. The expected result is that \/dev\/mapper\/tcrypt_name is created.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup open --type tcrypt \/path\/to\/container.tc tcrypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

For the first confirmation of an existing asset, read-only mounting should be the default. This does not mean that TrueCrypt \/ TCRYPT assets must never be updated again. Rather, during first confirmation, inventory, pre-migration investigation, or when the media state is uncertain, it is safer to inspect the contents while avoiding writes. The expected result is that existing files can be read under \/mnt\/tcrypt_name.<\/p>\n

1
<\/div><\/td>
sudo mount -o ro \/dev\/mapper\/tcrypt_name \/mnt\/tcrypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

However, when an existing TrueCrypt \/ TCRYPT asset is kept effectively as a compatibility backup, it does not always have to remain read-only. For example, if an existing TrueCrypt + FAT medium can still be opened, has no media-state problem, has a role as a compatibility backup separate from the primary LUKS2 system, and has documented update procedures and retirement conditions, it may be treated as a limited update target. Even in that case, before updating it, confirm that another backup path exists, perform a readability check after the update, and record the final update date and synchronization source in the inventory.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Positioning<\/th>\nTreatment<\/th>\nJudgment criterion<\/th>\n<\/tr>\n<\/thead>\n
current primary<\/td>\nDo not newly adopt it.<\/td>\nBecause it is no longer maintained, it should not be expanded as a current primary encrypted disk format.<\/td>\n<\/tr>\n
compatibility backup<\/td>\nKeep it with a limited role.<\/td>\nIf it remains useful as a path to past data, old environments, or a fallback when migration fails, document it and keep it.<\/td>\n<\/tr>\n
read-oriented archive<\/td>\nTreat it primarily as a target for read confirmation and data rescue.<\/td>\nIf updates are unnecessary and preservation of the past state is the main purpose, keep it read-oriented.<\/td>\n<\/tr>\n
limited update target<\/td>\nUpdate it conditionally.<\/td>\nAllow updates only when another backup path exists and update procedures, verification procedures, and retirement conditions are clear.<\/td>\n<\/tr>\n
migration target<\/td>\nSynchronize it to a current primary format such as LUKS2.<\/td>\nMigrate when maintenance discontinuation or media deterioration risk outweighs its value as a compatibility backup.<\/td>\n<\/tr>\n
retirement candidate<\/td>\nStop retaining it or securely erase it after recovery has been confirmed.<\/td>\nRetire it when equivalent data exists in the current primary and another independent path and its compatibility-backup role has ended.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

When updates are allowed in routine operation, open the TCRYPT container, mount it normally, perform the work, then close it with sync, umount, and close. The important point is not to keep using TrueCrypt \/ TCRYPT vaguely because it is old but still usable. The important point is to define how far updates are allowed under the role of compatibility backup. If it is treated as an update target, record that it is not primary, its update frequency, synchronization source, confirmation method, and retirement condition in the inventory.<\/p>\n

1
2
3
4
5
<\/div><\/td>
sudo cryptsetup open --type tcrypt \/path\/to\/container.tc tcrypt_name
\nsudo mount \/dev\/mapper\/tcrypt_name \/mnt\/tcrypt_name
\nsync
\nsudo umount \/mnt\/tcrypt_name
\nsudo cryptsetup close tcrypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

What should be avoided in managing existing TrueCrypt \/ TCRYPT assets is both treating them only as read-only migration sources and, conversely, continuing to use them exactly like current primary storage. The former undervalues their usefulness as compatibility backups. The latter leaves a discontinued format indefinitely in a primary role. The appropriate approach is to state that they are not current primary storage, but compatibility backups or migration targets, and to translate the conditions for confirmation, updating, synchronization, and retirement into operational design.<\/p>\n

The point of this chapter is not to decide simply that existing TrueCrypt \/ TCRYPT assets should be abolished because they are old. Discontinuation of maintenance is an important risk, but in long-term operation, the ability to reach past assets is also part of recoverability. Therefore, TrueCrypt \/ TCRYPT should not be adopted as a new primary format, while existing assets should be classified as compatibility backup, read-oriented archive, limited update target, migration target, or retirement candidate, managed while they still have a role, and retired without damaging recovery paths once that role ends.<\/p>\n

\n

16. Periodic inspection should test unlockability, keys, filesystem health, and media<\/h2>\n

Periodic inspection is not the same as running a single filesystem checker. An encrypted disk can fail at the opening layer, the filesystem layer, the media layer, or the documentation layer. A useful inspection confirms that the intended device is present, the LUKS header is readable, keyfile and emergency passphrase paths still work, the filesystem can be checked while unmounted, representative data can be read, SMART information is acceptable, and the inventory still matches reality.<\/p>\n

1
2
3
4
5
6
7
8
9
<\/div><\/td>
lsblk -f
\nsudo cryptsetup isLuks \/dev\/sdX
\nsudo cryptsetup luksDump \/dev\/sdX
\nsudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX
\nsudo cryptsetup open --test-passphrase \/dev\/sdX
\nsudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name
\nsudo e2fsck -f \/dev\/mapper\/crypt_name
\nsudo smartctl -a \/dev\/sdX
\nsudo cryptsetup close crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n\n\n\n\n\n\n\n\n\n\n
Periodic check<\/th>\nMinimum expected result<\/th>\nEscalation trigger<\/th>\n<\/tr>\n<\/thead>\n
Device identity<\/td>\nby-id, capacity, and LUKS UUID match inventory.<\/td>\nUnexpected device identity or missing expected media.<\/td>\n<\/tr>\n
Header readability<\/td>\nluksDump succeeds and slot state matches records.<\/td>\nHeader read errors or unexplained slot changes.<\/td>\n<\/tr>\n
Keyfile path<\/td>\ntest-passphrase succeeds with recorded keyfile.<\/td>\nKeyfile missing, checksum mismatch, or failed test.<\/td>\n<\/tr>\n
Emergency passphrase<\/td>\nManual test succeeds under controlled conditions.<\/td>\nForgotten passphrase or undocumented slot.<\/td>\n<\/tr>\n
Filesystem<\/td>\ne2fsck reports clean or repairs are documented.<\/td>\nRepeated repairs, uncorrectable errors, or suspicious metadata.<\/td>\n<\/tr>\n
Media<\/td>\nSMART output has no concerning trend.<\/td>\nReallocated sectors, pending sectors, I\/O errors, or sudden performance degradation.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The inspection interval should match the role of the asset. A primary backup target that is rewritten frequently deserves more frequent tests than a read-only compatibility copy. The minimum useful inspection is not a single e2fsck run; it is a controlled proof that the intended encrypted path still opens, the filesystem is still coherent, representative data can be read, the media has no alarming trend, and the written procedure still matches reality.<\/p>\n

\n

17. Migrate by creating a new LUKS2 target, synchronizing, verifying, and changing roles<\/h2>\n

Migration should not be performed by improvising on the old encrypted disk. The safer method is to create a new LUKS2 target, open both source and destination, synchronize data, verify the destination, switch configuration, and only then change the role of the old media. For file-based migration, rsync is usually the practical tool because it can perform repeated synchronization while the source remains active.<\/p>\n

17.1 Inspect the source before migration<\/h3>\n

Before creating or writing to a migration destination, inspect the source. The goal is to confirm that the source is the intended device, that its LUKS header is readable, and that at least one documented opening path still works. Migration from a questionable source is not an ordinary upgrade; it is partly a rescue operation and should be treated conservatively.<\/p>\n

1
2
3
4
<\/div><\/td>
lsblk -f
\nls -l \/dev\/disk\/by-id\/
\nsudo cryptsetup luksDump \/dev\/sdX
\nsudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/src.key \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that the physical device, by-id name, LUKS UUID, key slot state, and tested keyfile match the inventory. If the source cannot pass an unlock test, do not proceed directly to a normal migration. First decide whether the correct priority is data rescue, header recovery, key recovery, or media stabilization.<\/p>\n\n\n\n\n\n\n\n\n
Check<\/th>\nPurpose<\/th>\nAction if it fails<\/th>\n<\/tr>\n<\/thead>\n
lsblk -f<\/td>\nConfirms device hierarchy and mount state.<\/td>\nStop if the source device is not the expected asset.<\/td>\n<\/tr>\n
\/dev\/disk\/by-id<\/td>\nConfirms the physical medium.<\/td>\nResolve device identity before opening or copying.<\/td>\n<\/tr>\n
luksDump<\/td>\nConfirms LUKS metadata and key slot state.<\/td>\nTreat unreadable metadata as a recovery problem, not a migration routine.<\/td>\n<\/tr>\n
test-passphrase<\/td>\nConfirms that the documented key path still works.<\/td>\nUse another documented path or switch to recovery planning.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Only a source that can be identified, opened, and read under controlled conditions should enter a planned migration path. Otherwise, the first task is preserving readable data, not creating a new neat configuration.<\/p>\n

17.2 Create the destination as a new LUKS2 device<\/h3>\n

The destination should be created as a new encrypted asset, not as an improvised mutation of the old source. That means it receives its own LUKS UUID, keyfile, emergency passphrase, header backup, filesystem UUID, mount point, and lifecycle role. Creating the destination deliberately allows the source to remain intact until migration has been verified.<\/p>\n

1
2
3
4
5
<\/div><\/td>
sudo cryptsetup luksFormat --type luks2 \/dev\/sdY
\nsudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/dst.key \/dev\/sdY dst_crypt
\nsudo mkfs.ext4 \/dev\/mapper\/dst_crypt
\nsudo mkdir -p \/mnt\/dst
\nsudo mount \/dev\/mapper\/dst_crypt \/mnt\/dst<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that \/dev\/sdY becomes a new LUKS2 container, \/dev\/mapper\/dst_crypt appears after opening, and \/mnt\/dst becomes a writable filesystem. The destination identity must be recorded immediately. Do not postpone the inventory until after data copy, because the copy itself depends on knowing which device is the destination.<\/p>\n\n\n\n\n\n\n\n\n
Destination item<\/th>\nRecord immediately<\/th>\nReason<\/th>\n<\/tr>\n<\/thead>\n
LUKS identity<\/td>\nLUKS UUID, LUKS version, cipher, KDF.<\/td>\nPrevents confusion with the source or another new disk.<\/td>\n<\/tr>\n
Opening path<\/td>\nKeyfile path, keyfile checksum, emergency passphrase slot.<\/td>\nEnsures the new target can be opened after migration.<\/td>\n<\/tr>\n
Filesystem identity<\/td>\nFilesystem UUID, type, mount point.<\/td>\nSupports fstab and mount verification.<\/td>\n<\/tr>\n
Lifecycle role<\/td>\nPrimary, backup, replacement target, or temporary migration target.<\/td>\nPrevents the new disk from being mistaken for scratch media.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The destination is not trusted merely because it was freshly created. It becomes trusted only after it can be opened, mounted, written, read, closed, reopened, and verified independently.<\/p>\n

17.3 Open and mount the source read-only when appropriate<\/h3>\n

The source mount mode should be chosen deliberately. If the source is healthy and still in normal service, a planned migration may use normal access. If the source is old, suspicious, or being preserved for rescue, read-only access reduces the risk of changing it during migration.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/src.key \/dev\/sdX src_crypt
\nsudo mkdir -p \/mnt\/src
\nsudo mount -o ro \/dev\/mapper\/src_crypt \/mnt\/src<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

If the source is known healthy and still active, a read-write mount may be part of a controlled migration. If the source is old, suspicious, or retained only for rescue, a read-only mount is safer. The migration procedure should state which mode is intended.<\/p>\n

17.4 Synchronize data<\/h3>\n

Data synchronization should be performed with a command that can be repeated and audited. rsync is useful because it can perform an initial bulk copy and later follow-up passes. The exact options depend on the filesystem, ownership model, ACL usage, extended attributes, and whether the destination is intended to preserve system-like metadata.<\/p>\n

1
2
<\/div><\/td>
sudo rsync -aHAX --numeric-ids \/mnt\/src\/ \/mnt\/dst\/
\nsync<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that the destination receives the source contents while preserving the metadata required by the intended use case. The sync command marks a clear writeback boundary before verification. Record the exact command, source path, destination path, date, excluded paths if any, and whether the source was mounted read-only or read-write.<\/p>\n\n\n\n\n\n\n\n\n
rsync aspect<\/th>\nOperational meaning<\/th>\nDecision point<\/th>\n<\/tr>\n<\/thead>\n
Archive behavior<\/td>\nPreserves basic file attributes and directory structure.<\/td>\nUsually required for backup-like migration.<\/td>\n<\/tr>\n
Hard links<\/td>\nPreserves hard-link relationships.<\/td>\nImportant for some system trees and deduplicated layouts.<\/td>\n<\/tr>\n
ACLs and xattrs<\/td>\nPreserves extended metadata when supported.<\/td>\nUse only when source and destination filesystems and tools support them.<\/td>\n<\/tr>\n
–delete<\/td>\nMakes destination mirror source by removing extra files.<\/td>\nUse only in the final mirror pass when that behavior is intended.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The purpose of synchronization is not merely to move bytes. It is to create a destination that can assume the source\u2019s operational role. That requires later verification, not just an rsync exit code.<\/p>\n

17.5 Repeat synchronization after writes stop<\/h3>\n

When the source can change during migration, the first copy is only a bulk transfer. A later pass after writes have stopped is needed to reduce drift and define the destination as a coherent replacement.<\/p>\n

1
2
<\/div><\/td>
sudo rsync -aHAX --numeric-ids --delete \/mnt\/src\/ \/mnt\/dst\/
\nsync<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

When the source is active during migration, the first synchronization is only a bulk copy. A second pass after writes stop reduces drift. The –delete option is powerful and should be used only when the destination is meant to mirror the source. It should not be used casually when the destination already contains independent data.<\/p>\n

17.6 Verify the destination independently<\/h3>\n

Destination verification must not rely on the source still being available. The destination should be closed, reopened, mounted, read, and checked as its own encrypted asset.<\/p>\n

1
2
3
4
5
<\/div><\/td>
sudo umount \/mnt\/dst
\nsudo cryptsetup close dst_crypt
\nsudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/dst.key \/dev\/sdY dst_crypt
\nsudo mount \/dev\/mapper\/dst_crypt \/mnt\/dst
\nfind \/mnt\/dst -maxdepth 2 -type f | head<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Verification must not depend on the original shell session. Close and reopen the destination, mount it again, read representative data, and confirm that permissions and ownership behave as expected. A migration is not complete simply because rsync ended with exit code 0.<\/p>\n

17.7 Switch boot or mount configuration after verification<\/h3>\n

Only after independent destination verification should crypttab, fstab, scripts, or operational procedures be switched. The new LUKS UUID belongs in the unlocking configuration, and the new filesystem UUID belongs in the mount configuration. Preserve the old entries long enough to recover if the new setup fails, but do not leave ambiguous duplicate entries active.<\/p>\n

1
2
3
4
<\/div><\/td>
sudo blkid
\ncat \/etc\/crypttab
\ncat \/etc\/fstab
\nlsblk -f<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that the new crypttab entry points to the destination LUKS UUID and the new fstab entry points to the destination filesystem UUID. After editing, close and reopen the new destination, mount it through the configured path, and confirm that scripts or backup jobs no longer depend on the old mapper name or old mount point unless that dependency is intentional.<\/p>\n\n\n\n\n\n\n\n\n
Configuration item<\/th>\nMust change to<\/th>\nRisk if not changed<\/th>\n<\/tr>\n<\/thead>\n
crypttab<\/td>\nDestination LUKS UUID and destination key path.<\/td>\nThe system may keep opening the old encrypted disk.<\/td>\n<\/tr>\n
fstab<\/td>\nDestination filesystem UUID and intended mount point.<\/td>\nThe system may mount the wrong filesystem or fail at boot.<\/td>\n<\/tr>\n
Scripts<\/td>\nNew mapper name or stable mount point.<\/td>\nAutomation may silently continue writing to the old media.<\/td>\n<\/tr>\n
Inventory<\/td>\nNew primary role and old downgraded role.<\/td>\nFuture recovery may depend on the wrong asset.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Configuration switching is part of migration, not an afterthought. The migration is incomplete while routine operations still point to the old storage path.<\/p>\n

17.8 Change the old role instead of deleting immediately<\/h3>\n

The old encrypted disk should normally become a compatibility backup or migration source for a defined interval before final retirement. Immediate erasure is appropriate only when there are verified independent copies and the old asset no longer serves any recovery purpose. Role change is safer than instant destruction.<\/p>\n

17.9 Define migration completion<\/h3>\n

Migration is not complete when rsync finishes. rsync completion only means a copy command ended under a particular runtime state. A migration becomes operationally complete only when the destination can stand on its own: it opens independently, mounts independently, contains the expected data, has usable keys and header backups, and is reflected in the inventory and system configuration. The source should not be retired before those conditions are true.<\/p>\n\n\n\n\n\n\n\n\n\n
Completion condition<\/th>\nRequired evidence<\/th>\nWhy it matters<\/th>\n<\/tr>\n<\/thead>\n
Destination opens<\/td>\nKeyfile and emergency passphrase tests pass.<\/td>\nConfirms future access.<\/td>\n<\/tr>\n
Destination mounts<\/td>\nFilesystem UUID and mount point work after reopen.<\/td>\nConfirms filesystem usability.<\/td>\n<\/tr>\n
Data is readable<\/td>\nRepresentative files and directories are checked.<\/td>\nConfirms that copied data is not merely listed but readable.<\/td>\n<\/tr>\n
Configuration is updated<\/td>\ncrypttab, fstab, and scripts refer to the new target.<\/td>\nPrevents accidental continued dependence on old media.<\/td>\n<\/tr>\n
Old role is recorded<\/td>\nCompatibility backup, retired, reused, or disposed.<\/td>\nPrevents old media from remaining silently critical.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The old source should then receive a new explicit role. It may become a read-only compatibility backup, a temporary rollback source, reusable blank media, or a retired asset. Leaving it in an unnamed intermediate state creates future confusion: someone may trust it as primary, overwrite it as spare media, or forget that it is the only remaining fallback.<\/p>\n

\n

18. Recover in the order: observe, unlock, read, rescue, repair<\/h2>\n

Recovery is where lifecycle discipline matters most. The worst response to an uncertain encrypted disk is to start repairing immediately. First observe the device identity and layer structure. Then confirm whether the LUKS header is readable. Then test the keyfile and emergency passphrase. Then create the mapper if possible. Then prefer read-only mounting. Then copy important data away. Only after rescue should filesystem repair or header restoration be considered.<\/p>\n

18.1 Confirm that the target is not mistaken<\/h3>\n

Recovery pressure makes target mistakes more likely. Begin by confirming the physical device, capacity, role, and by-id mapping. A damaged or ambiguous environment is exactly the situation in which transient names such as \/dev\/sdX are least trustworthy.<\/p>\n

1
2
<\/div><\/td>
lsblk -f
\nls -l \/dev\/disk\/by-id\/<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that the device being inspected matches the physical medium and operational role recorded in the inventory. Do not attempt repair, header restoration, filesystem checks, or erase operations on a device selected only by a transient name. If the by-id mapping or capacity does not match the record, stop and resolve the identity problem first.<\/p>\n

18.2 Check whether the LUKS header is readable<\/h3>\n

After confirming the target identity, check whether the device is recognizable as LUKS and whether the header can be inspected. This step separates a device-identity problem from a LUKS-metadata problem. It also tells whether later keyfile or passphrase testing is meaningful.<\/p>\n

1
2
<\/div><\/td>
sudo cryptsetup isLuks \/dev\/sdX
\nsudo cryptsetup luksDump \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

If luksDump works, the header is readable enough for metadata inspection. Record the LUKS UUID, version, and key slot state before making changes. If it fails, do not immediately restore a header. First confirm that the correct disk or partition boundary is being used and that the device has not been misidentified.<\/p>\n

18.3 Test keyfile and emergency passphrase<\/h3>\n

Before creating a mapper or attempting repair, test the documented opening paths without changing the device state. This is where the distinction between normal keyfile operation and emergency passphrase recovery matters. A failure of one path does not prove that all recovery paths are lost.<\/p>\n

1
2
<\/div><\/td>
sudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX
\nsudo cryptsetup open --test-passphrase \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is that at least one documented opening path succeeds. If the keyfile works but the emergency passphrase does not, the passphrase record may be stale or assigned to a removed slot. If the emergency passphrase works but the keyfile does not, inspect keyfile path, contents, permissions, and custody. Do not add, remove, or kill key slots during the first recovery pass.<\/p>\n

18.4 Create the mapper and inspect its state<\/h3>\n

If the key test succeeds, create the mapper and inspect its state before attempting filesystem work. This step establishes whether the encryption layer has been crossed and whether later failures belong to the filesystem or LVM layer.<\/p>\n

1
2
3
<\/div><\/td>
sudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name
\nsudo cryptsetup status crypt_name
\nlsblk -f<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

If the mapper exists, the encryption layer has been opened. The next questions are filesystem state, LVM state, and data readability. If the mapper cannot be created, focus on key material, header state, device identity, or possible metadata damage.<\/p>\n

18.5 Determine LVM order before activating or repairing<\/h3>\n

If LVM is present, determine the layer order before activating volumes or running repair commands. The correct order depends on whether LVM is inside LUKS or LUKS is inside LVM.<\/p>\n

1
2
3
4
<\/div><\/td>
sudo pvs
\nsudo vgs
\nsudo lvs
\nlsblk -f<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

If LVM is present, determine whether LVM is inside LUKS or LUKS is inside LVM before proceeding. Activating the wrong layer first may not destroy data by itself, but it wastes recovery time and increases the chance of later incorrect repair commands.<\/p>\n

18.6 Mount read-only first<\/h3>\n

When the mapper can be created, the next priority is to see whether the filesystem can be read without changing it. Read-only mounting reduces the risk of metadata changes before important data has been copied away. This is especially important when the failure cause is unknown or when media health is suspicious.<\/p>\n

1
2
<\/div><\/td>
sudo mkdir -p \/mnt\/recovery
\nsudo mount -o ro \/dev\/mapper\/crypt_name \/mnt\/recovery<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is a readable mount at \/mnt\/recovery. If read-only mounting succeeds, the first task is rescuing important data, not optimizing the source filesystem. If read-only mounting fails while the mapper exists, the problem is likely in the filesystem layer, the mount options, or an LVM layer that has not yet been handled.<\/p>\n

18.7 Rescue important data while it is readable<\/h3>\n

Once data is readable, the priority is rescue. Repair plans and structural cleanup can wait; important data should be copied while the source still answers reads.<\/p>\n

1
2
<\/div><\/td>
sudo rsync -aHAX --numeric-ids \/mnt\/recovery\/ \/mnt\/rescue-target\/
\nsync<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Copy the most important data first. Do not spend the first recovery window optimizing the repair plan while the only readable copy remains at risk. If the source is unstable, prioritize irreplaceable files, inventory files, keys, configuration, and recent changes.<\/p>\n

18.8 Decide on filesystem repair only after rescue<\/h3>\n

Filesystem repair should come after observation and rescue, not before. e2fsck can be the correct tool for ext-family filesystem repair, but it can also change filesystem metadata. When a failing disk is still readable, the safer priority is to copy valuable data first and repair the source second.<\/p>\n

1
2
<\/div><\/td>
sudo umount \/mnt\/recovery
\nsudo e2fsck -f \/dev\/mapper\/crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected precondition is that the filesystem is unmounted and important readable data has already been copied elsewhere if possible. If repair succeeds, remount and verify representative files. If repair reports severe errors or the device shows media problems, stop treating the source as trustworthy and focus on the rescued copy or a new migration target.<\/p>\n

18.9 Treat LUKS header restoration as the last metadata option<\/h3>\n

LUKS header restoration is a metadata-writing recovery action, not a routine check. It can be necessary when the header is damaged and a matching backup exists, but it can also make recovery worse if the backup belongs to the wrong device or an obsolete slot state. It should be considered only after target identity, header readability, key material, and read-only rescue possibilities have been evaluated.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup luksHeaderRestore \/dev\/sdX --header-backup-file luks-header-crypt_name-YYYYMMDD.img<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The required precondition is a header backup whose filename, checksum, LUKS UUID, creation date, device identity, and key slot state match the recovery target. A stale header backup may remove newer key slot changes. A header from another device may break access rather than restore it. Treat this command as a last metadata option and document the outcome immediately.<\/p>\n

18.10 Confirm normal operation after recovery<\/h3>\n

After emergency recovery or repair, confirm that the device still works through the normal operational path. A one-time recovery mount is not enough if routine unlocking, mounting, and closing remain broken.<\/p>\n

1
2
3
4
5
6
<\/div><\/td>
sudo cryptsetup close crypt_name
\nsudo cryptsetup open --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX crypt_name
\nsudo mount \/dev\/mapper\/crypt_name \/mnt\/crypt_name
\nsync
\nsudo umount \/mnt\/crypt_name
\nsudo cryptsetup close crypt_name<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Recovery is not complete until normal opening, mounting, reading, unmounting, and closing work again. If the recovered device is no longer trustworthy, the correct completion step may be migration to a new target rather than returning the old device to normal service.<\/p>\n

18.11 Record the recovery outcome<\/h3>\n

Recovery records are part of future resilience. They should describe not only what was fixed, but what was observed before repair and what data was rescued before any destructive action. Without that record, a later operator cannot tell whether the device failed because of media deterioration, filesystem damage, keyfile loss, header damage, LVM confusion, or a procedural mistake.<\/p>\n\n\n\n\n\n\n\n\n\n
Recovery record<\/th>\nRequired content<\/th>\nPurpose<\/th>\n<\/tr>\n<\/thead>\n
Initial symptom<\/td>\nWhat failed and when.<\/td>\nPreserves incident context.<\/td>\n<\/tr>\n
Layer diagnosis<\/td>\nDevice, LUKS, mapper, LVM, filesystem, or media.<\/td>\nPrevents the same issue from being misdiagnosed later.<\/td>\n<\/tr>\n
Actions taken<\/td>\nCommands, dates, and whether they wrote metadata.<\/td>\nShows what changed during recovery.<\/td>\n<\/tr>\n
Data rescued<\/td>\nTarget path, scope, and verification result.<\/td>\nConfirms what was preserved.<\/td>\n<\/tr>\n
Future role<\/td>\nReturn to service, migrate, compatibility backup, or retire.<\/td>\nConnects recovery to lifecycle management.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This record also prevents repeated unsafe troubleshooting. If a header restore was attempted, if e2fsck modified metadata, or if only part of the data could be read, that fact must remain visible. Recovery should reduce uncertainty for the next incident, not only solve the immediate one.<\/p>\n

\n

19. Retire encrypted devices without destroying recovery knowledge prematurely<\/h2>\n

Retirement is not simply deleting an old disk. It is the controlled removal of an encrypted asset from the set of operationally required recovery paths. Before retirement, confirm that the data exists on the new primary target, exists on another backup path, can be opened independently, and has been read at least partially after migration. Then decide what to do with the LUKS header backup, keyfiles, emergency passphrase records, crypttab entries, fstab entries, labels, and physical media.<\/p>\n

19.1 Confirm replacement and alternate recovery paths<\/h3>\n

Before retiring a LUKS device, verify that the replacement device opens independently, mounts independently, and contains readable data. Also verify that another backup path exists. A single successful migration copy is not enough if the old source is about to become unrecoverable.<\/p>\n

1
2
3
<\/div><\/td>
lsblk -f
\nsudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/new.key \/dev\/sdY
\nsudo mount \/dev\/mapper\/new_crypt \/mnt\/new<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

The expected result is independent access to the replacement without relying on the old device. If the new target cannot be opened or mounted without the old media present, retirement is premature. The alternate recovery path can be another backup disk, a verified archive, or another documented copy, but it must be tested rather than assumed.<\/p>\n

19.2 Inspect the current state of the retirement target<\/h3>\n

Retirement should be based on the current device state, not memory. Before changing or destroying an old encrypted device, inspect its identity, header, key paths, and role.<\/p>\n

1
2
3
<\/div><\/td>
lsblk -f
\nsudo cryptsetup luksDump \/dev\/sdX
\nsudo cryptsetup open --test-passphrase --key-file \/etc\/cryptsetup-keys\/crypt_name.key \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

Retirement should be based on the actual current state, not memory. The device may have a different role, different slot state, or different contents than expected. Confirm before changing or destroying it.<\/p>\n

19.3 Decide what happens to headers and keys<\/h3>\n

Retirement changes the status of header backups, keyfiles, and emergency passphrase records. These artifacts are useful while the old device remains a recovery path, but they become sensitive obsolete material once the device is intentionally made unrecoverable. The decision must follow the device role, not the other way around.<\/p>\n\n\n\n\n\n\n\n\n
Old-device role<\/th>\nHeader backup<\/th>\nKey material<\/th>\n<\/tr>\n<\/thead>\n
Compatibility backup<\/td>\nKeep and label it with matching LUKS UUID and date.<\/td>\nKeep documented keyfile or emergency passphrase access.<\/td>\n<\/tr>\n
Temporary rollback source<\/td>\nKeep until rollback window ends.<\/td>\nKeep only for the defined rollback period.<\/td>\n<\/tr>\n
Reusable blank media<\/td>\nMark obsolete or destroy after migration proof.<\/td>\nRemove from active key inventories.<\/td>\n<\/tr>\n
Disposed media<\/td>\nRetain only sanitization evidence, not usable recovery material unless required by policy.<\/td>\nDestroy or mark obsolete according to the retirement record.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Do not destroy recovery metadata while the old encrypted device still serves as a backup path. Conversely, do not leave live key material for a device that has been intentionally retired and should no longer be recoverable.<\/p>\n

19.4 Role change is not retirement<\/h3>\n

If a device is kept as a compatibility backup, it has not been retired. Its role has changed. The inventory should say that it is no longer primary, whether it is read-only, what software can open it, where the key material is stored, when it was last tested, and under what condition it may be destroyed.<\/p>\n

19.5 Understand cryptsetup erase before using it<\/h3>\n

cryptsetup erase is not a cleanup convenience. It intentionally removes LUKS key material and can make the encrypted payload unrecoverable. It belongs only in a retirement path where irreversible loss of access is intended.<\/p>\n

1
<\/div><\/td>
sudo cryptsetup erase \/dev\/sdX<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

cryptsetup erase destroys LUKS key material and can render the encrypted data unrecoverable. That can be appropriate when the intent is irreversible retirement. It is not appropriate when the old device is being kept as a compatibility backup. If the device is retained, the operation is not retirement but role change.<\/p>\n

19.6 Separate media reuse from media disposal<\/h3>\n

Reusing a physical disk and disposing of it are different operations. Reuse removes the old encrypted role but keeps the medium under control. Disposal removes the physical medium from control and therefore requires sanitization evidence appropriate to the threat model. A disk can leave encrypted service without leaving the environment, and a disk can leave the environment only after the data exposure question has been closed.<\/p>\n\n\n\n\n\n\n\n
Outcome<\/th>\nWhat happens to the medium<\/th>\nRequired record<\/th>\n<\/tr>\n<\/thead>\n
Reuse internally<\/td>\nThe disk receives a new role after the old encrypted role is removed.<\/td>\nMigration proof, old-role removal, new role, and date.<\/td>\n<\/tr>\n
Keep offline<\/td>\nThe disk remains as a compatibility or emergency backup.<\/td>\nOpening method, last test date, read-only policy, and storage location.<\/td>\n<\/tr>\n
Dispose<\/td>\nThe disk leaves physical control.<\/td>\nSanitization method, date, operator, and confirmation result.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

This distinction prevents false retirement. A disk kept as a compatibility backup is not retired. A disk reused internally must not still be required for recovery. A disk disposed of must not retain unaccounted recovery material or undocumented sensitive data.<\/p>\n

19.7 Define retirement completion<\/h3>\n

Retirement completion must be defined before destructive action. There is a major difference between a disk that is no longer primary, a disk that is retained as a compatibility backup, a disk that has been erased for reuse, and a disk that has left physical control. Each state has different requirements for keys, header backups, labels, inventory, and proof of migration.<\/p>\n\n\n\n\n\n\n\n
Decision<\/th>\nMeaning<\/th>\nRequired record<\/th>\n<\/tr>\n<\/thead>\n
Keep as compatibility backup<\/td>\nThe old encrypted asset remains a recovery path.<\/td>\nOpening method, last test date, read-only policy, and replacement target.<\/td>\n<\/tr>\n
Reuse media<\/td>\nThe encrypted asset is removed, but the physical disk remains in service.<\/td>\nData migration proof, erase or reformat method, and new role.<\/td>\n<\/tr>\n
Dispose of media<\/td>\nThe physical device leaves control.<\/td>\nSanitization method, date, operator, and confirmation result.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The retirement state should be visible to future operators. If the media is kept, the label and inventory should say why it is kept and how it can be opened. If it is erased, the record should say which erase method was used and when. If it is disposed of, the sanitization evidence should remain outside the disposed media. Retirement without records is only another form of operational amnesia.<\/p>\n

\n

20. Make prohibited operations explicit<\/h2>\n

Encrypted disk procedures need a short list of operations that must not be performed casually. These prohibitions are more useful than vague warnings because they connect specific commands to specific failure modes. In operational documentation, \u201cbe careful\u201d is weak. \u201cDo not run mkfs on \/dev\/sdX when the intended target is \/dev\/mapper\/name\u201d is strong because it names the dangerous action and the required distinction.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Operation to avoid<\/th>\nWhy it is dangerous<\/th>\nRequired precondition if ever performed<\/th>\n<\/tr>\n<\/thead>\n
Running luksFormat on an uncertain target<\/td>\nIt destroys the prior interpretation of the target device.<\/td>\nConfirmed by lsblk, by-id, inventory, and operator intent.<\/td>\n<\/tr>\n
Running mkfs on \/dev\/sdX instead of \/dev\/mapper\/name<\/td>\nIt can overwrite the LUKS structure or the wrong disk.<\/td>\nConfirmed mapper exists and the operation is initial filesystem creation.<\/td>\n<\/tr>\n
Deleting a key slot before testing another path<\/td>\nThe last valid opening path can be removed.<\/td>\nAnother keyfile or emergency passphrase has just passed test-passphrase.<\/td>\n<\/tr>\n
Restoring a header backup by filename alone<\/td>\nA stale or wrong header can damage recovery prospects.<\/td>\nLUKS UUID, device identity, date, checksum, and slot state match the record.<\/td>\n<\/tr>\n
Repairing a filesystem before rescue<\/td>\nRepair can change metadata and reduce recovery options.<\/td>\nImportant readable data has already been copied elsewhere if possible.<\/td>\n<\/tr>\n
Keeping undocumented old encrypted media<\/td>\nThe data may exist physically but become operationally unrecoverable.<\/td>\nOpening method, role, test date, and retirement condition are recorded.<\/td>\n<\/tr>\n
Destroying header backups while the device remains a backup<\/td>\nThe backup path may become unrecoverable after a metadata fault.<\/td>\nThe asset has been formally retired and no longer serves as a recovery path.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The second half of the rule is to state the safe alternative. A prohibition is useful only when it tells the operator where to stop and what to verify instead. Each dangerous action should be paired with a verification boundary: identify the device before luksFormat, confirm the mapper before mkfs, test another key before slot deletion, match metadata before header restore, rescue before repair, and define the asset role before destroying recovery material.<\/p>\n\n\n\n\n\n\n\n\n\n
Unsafe impulse<\/th>\nSafer first action<\/th>\nReason<\/th>\n<\/tr>\n<\/thead>\n
\u201cInitialize this disk now.\u201d<\/td>\nRun lsblk -f and verify \/dev\/disk\/by-id.<\/td>\nPrevents target confusion.<\/td>\n<\/tr>\n
\u201cRemove the old key slot.\u201d<\/td>\nTest another opening path first.<\/td>\nPrevents loss of the last valid unlock path.<\/td>\n<\/tr>\n
\u201cRestore the header backup.\u201d<\/td>\nCompare UUID, checksum, date, and slot state.<\/td>\nPrevents applying stale or wrong metadata.<\/td>\n<\/tr>\n
\u201cRun repair immediately.\u201d<\/td>\nMount read-only and copy important data if possible.<\/td>\nPreserves recovery options before metadata changes.<\/td>\n<\/tr>\n
\u201cDelete the old encrypted disk.\u201d<\/td>\nConfirm replacement, alternate backup, and old-role decision.<\/td>\nPrevents premature destruction of a recovery path.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The purpose of this list is not to make operations slower. It is to make irreversible operations explicit. Encrypted storage fails harshly when the last valid opening path, matching header, or recoverable source copy is lost. Written prohibitions create a boundary that a tired operator can still follow.<\/p>\n

\n

21. Keep an inventory that supports recovery decisions<\/h2>\n

The inventory should not become a diary of every command ever typed. It should preserve the information needed to decide what the device is, how to open it, how to mount it, how to recover it, how to migrate it, and when to retire it. This is a resilience artifact, not a note-taking exercise. The same principle appears in broader operational writing about preserving meaning for the future self and about physical media management in backup and recovery strategy[39]<\/a>[40]<\/a>.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Inventory item<\/th>\nRecord<\/th>\nRecovery value<\/th>\n<\/tr>\n<\/thead>\n
Physical device<\/td>\nModel, serial, by-id path, physical label, capacity.<\/td>\nPrevents target confusion.<\/td>\n<\/tr>\n
LUKS identity<\/td>\nLUKS UUID, version, cipher, KDF, creation date.<\/td>\nIdentifies the encrypted container.<\/td>\n<\/tr>\n
Opening paths<\/td>\nKeyfile path, checksum, emergency passphrase custody, slot numbers.<\/td>\nPreserves unlockability.<\/td>\n<\/tr>\n
Mapper and filesystem<\/td>\nMapper name, filesystem UUID, type, mount point.<\/td>\nConnects crypttab and fstab reasoning.<\/td>\n<\/tr>\n
LVM structure<\/td>\nPV, VG, LV, and whether LVM is above or below LUKS.<\/td>\nPreserves the activation and recovery order.<\/td>\n<\/tr>\n
Header backups<\/td>\nFilename, date, checksum, storage location, matching LUKS UUID.<\/td>\nSupports last-resort metadata recovery.<\/td>\n<\/tr>\n
Inspection state<\/td>\nLast open test, last filesystem check, last SMART check, last read verification.<\/td>\nShows whether the asset is still operational.<\/td>\n<\/tr>\n
Lifecycle role<\/td>\nPrimary, backup, compatibility backup, migration source, retired.<\/td>\nPrevents obsolete assets from remaining silently critical.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

An effective inventory is concise but decisive. It does not need every shell transcript, but it must contain enough information to rebuild the opening path without relying on memory. If the operator who created the device disappears, the inventory should still allow another competent operator to identify the device, open it, mount it, inspect it, rescue it, migrate it, or retire it.<\/p>\n

\n

22. The operating procedure is the real resilience mechanism<\/h2>\n

LUKS operation is not only a cryptographic matter. It is an operational resilience matter. Strong encryption protects confidentiality only while the system remains openable by legitimate operators and closed to unauthorized ones. A beautifully configured disk whose keyfile is lost, whose header backup is unlabeled, whose UUIDs are confused, whose LVM order is undocumented, or whose old media role is unknown is not resilient. Conversely, a modest but well-documented configuration can remain useful for years because the opening path, inspection method, recovery route, migration plan, and retirement condition are known.<\/p>\n

The practical conclusion is that encrypted disk operation must be written as a lifecycle. Creation defines the encrypted boundary. Routine use proves that the boundary can be opened and closed safely. Inspection proves that the recorded state still matches the actual state. Key management controls legitimate opening paths. Header backup preserves metadata recovery options. crypttab and fstab connect the encrypted layer to boot and mount behavior. LVM documentation preserves activation order. Periodic checks detect drift. Migration replaces an asset without destroying fallback paths. Recovery proceeds by observation before repair. Retirement removes an asset only after its recovery role is no longer needed.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Operational principle<\/th>\nConcrete expression<\/th>\nResilience value<\/th>\n<\/tr>\n<\/thead>\n
Observe before changing<\/td>\nUse lsblk, by-id, luksDump, status, blkid, and LVM commands before destructive actions.<\/td>\nPrevents repair attempts against the wrong layer or device.<\/td>\n<\/tr>\n
Separate layers<\/td>\nDistinguish physical device, LUKS, mapper, filesystem, mount point, and LVM.<\/td>\nMakes failures diagnosable.<\/td>\n<\/tr>\n
Test opening paths<\/td>\nUse test-passphrase for keyfiles and emergency passphrases.<\/td>\nPrevents silent loss of legitimate access.<\/td>\n<\/tr>\n
Preserve metadata<\/td>\nBack up headers with UUID, checksum, date, and slot-state records.<\/td>\nMaintains last-resort recovery options.<\/td>\n<\/tr>\n
Assign roles<\/td>\nLabel assets as primary, backup, compatibility backup, migration source, or retired.<\/td>\nPrevents old media from remaining silently critical.<\/td>\n<\/tr>\n
Retire deliberately<\/td>\nErase or dispose only after replacement and alternate recovery paths are verified.<\/td>\nPrevents cleanup from becoming data loss.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The practical conclusion is simple. Create encrypted disks deliberately. Identify targets before destructive operations. Separate LUKS, mapper, filesystem, mount, and LVM layers. Test every opening path. Back up headers with metadata. Configure crypttab and fstab as different layers. Inspect filesystems and media separately. Treat old TrueCrypt and TCRYPT assets as compatibility backups, not invisible primary storage. Migrate by building and verifying a new target. Recover by observing before repairing. Retire only after recovery routes are no longer needed. Existing operational articles on LUKS procedure, preserving TrueCrypt assets, and the original Japanese version of this guide provide adjacent practical background[41]<\/a>[42]<\/a>[43]<\/a>[44]<\/a>[45]<\/a>.<\/p>\n

An encrypted disk remains useful not because it was once formatted correctly, but because its lifecycle remains understandable. That is the difference between a one-time setup and an operational asset.<\/p>\n

\n

References<\/h2>\n
    \n
  1. id774, \u6697\u53f7\u5316\u30c7\u30a3\u30b9\u30af\u3092\u9577\u671f\u904b\u7528\u3059\u308b\u305f\u3081\u306e\u8a2d\u8a08\uff082026-05-30\uff09. https:\/\/blog.id774.net\/entry\/2026\/05\/30\/4818\/<\/a><\/li>\n
  2. cryptsetup project, cryptsetup. https:\/\/gitlab.com\/cryptsetup\/cryptsetup<\/a><\/li>\n
  3. Linux Kernel Documentation, dm-crypt. https:\/\/docs.kernel.org\/admin-guide\/device-mapper\/dm-crypt.html<\/a><\/li>\n
  4. man7.org, cryptsetup(8). https:\/\/man7.org\/linux\/man-pages\/man8\/cryptsetup.8.html<\/a><\/li>\n
  5. Arch manual pages, cryptsetup(8). https:\/\/man.archlinux.org\/man\/cryptsetup.8<\/a><\/li>\n
  6. Debian manpages, cryptsetup(8). https:\/\/manpages.debian.org\/stretch\/cryptsetup-bin\/cryptsetup.8.en.html<\/a><\/li>\n
  7. Red Hat Documentation, Encrypting block devices using LUKS. https:\/\/docs.redhat.com\/en\/documentation\/red_hat_enterprise_linux\/9\/html\/security_hardening\/encrypting-block-devices-using-luks_security-hardening<\/a><\/li>\n
  8. cryptsetup Wiki, Frequently Asked Questions. https:\/\/gitlab.com\/cryptsetup\/cryptsetup\/-\/wikis\/FrequentlyAskedQuestions<\/a><\/li>\n
  9. cryptsetup Wiki, LUKS standard on-disk format specification version 1.2.1. https:\/\/gitlab.com\/cryptsetup\/cryptsetup\/-\/wikis\/LUKS-standard\/on-disk-format.pdf<\/a><\/li>\n
  10. cryptsetup Wiki, LUKS2 On-Disk Format Specification. https:\/\/gitlab.com\/cryptsetup\/LUKS2-docs\/-\/blob\/main\/luks2_doc_wip.pdf<\/a><\/li>\n
  11. man7.org, cryptsetup-open(8). https:\/\/man7.org\/linux\/man-pages\/man8\/cryptsetup-open.8.html<\/a><\/li>\n
  12. man7.org, mke2fs(8). https:\/\/man7.org\/linux\/man-pages\/man8\/mke2fs.8.html<\/a><\/li>\n
  13. man7.org, cryptsetup-close(8). https:\/\/man7.org\/linux\/man-pages\/man8\/cryptsetup-close.8.html<\/a><\/li>\n
  14. man7.org, lsblk(8). https:\/\/man7.org\/linux\/man-pages\/man8\/lsblk.8.html<\/a><\/li>\n
  15. man7.org, blkid(8). https:\/\/man7.org\/linux\/man-pages\/man8\/blkid.8.html<\/a><\/li>\n
  16. man7.org, cryptsetup-luksRemoveKey(8). https:\/\/man7.org\/linux\/man-pages\/man8\/cryptsetup-luksRemoveKey.8.html<\/a><\/li>\n
  17. systemd, crypttab. https:\/\/www.freedesktop.org\/software\/systemd\/man\/latest\/crypttab.html<\/a><\/li>\n
  18. systemd, systemd-cryptsetup-generator. https:\/\/www.freedesktop.org\/software\/systemd\/man\/latest\/systemd-cryptsetup-generator.html<\/a><\/li>\n
  19. man7.org, fstab(5). https:\/\/man7.org\/linux\/man-pages\/man5\/fstab.5.html<\/a><\/li>\n
  20. man7.org, systemd.mount(5). https:\/\/man7.org\/linux\/man-pages\/man5\/systemd.mount.5.html<\/a><\/li>\n
  21. Red Hat Documentation, The Device Mapper. https:\/\/docs.redhat.com\/en\/documentation\/red_hat_enterprise_linux\/7\/html\/logical_volume_manager_administration\/device_mapper<\/a><\/li>\n
  22. Red Hat Documentation, Configuring and managing logical volumes. https:\/\/docs.redhat.com\/en\/documentation\/red_hat_enterprise_linux\/8\/html-single\/configuring_and_managing_logical_volumes\/index<\/a><\/li>\n
  23. man7.org, e2fsck(8). https:\/\/man7.org\/linux\/man-pages\/man8\/e2fsck.8.html<\/a><\/li>\n
  24. man7.org, fsck(8). https:\/\/man7.org\/linux\/man-pages\/man8\/fsck.8.html<\/a><\/li>\n
  25. smartmontools, smartmontools. https:\/\/www.smartmontools.org\/<\/a><\/li>\n
  26. NIST, FIPS 197, Advanced Encryption Standard (AES). https:\/\/csrc.nist.gov\/pubs\/fips\/197\/final<\/a><\/li>\n
  27. NIST, SP 800-38A, Recommendation for Block Cipher Modes of Operation. https:\/\/csrc.nist.gov\/pubs\/sp\/800\/38\/a\/final<\/a><\/li>\n
  28. NIST, SP 800-38E, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. https:\/\/csrc.nist.gov\/pubs\/sp\/800\/38\/e\/final<\/a><\/li>\n
  29. IETF, RFC 8018, PKCS #5: Password-Based Cryptography Specification Version 2.1. https:\/\/datatracker.ietf.org\/doc\/html\/rfc8018<\/a><\/li>\n
  30. IETF, RFC 9106, Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. https:\/\/datatracker.ietf.org\/doc\/rfc9106\/<\/a><\/li>\n
  31. NIST, Proposal to Update SP 800-38E. https:\/\/csrc.nist.gov\/News\/2023\/proposal-to-update-sp-800-38e<\/a><\/li>\n
  32. NIST, SP 800-57 Part 1 Rev. 5, Recommendation for Key Management. https:\/\/csrc.nist.gov\/pubs\/sp\/800\/57\/pt1\/r5\/final<\/a><\/li>\n
  33. NIST, SP 800-131A, Transitioning the Use of Cryptographic Algorithms and Key Lengths. https:\/\/csrc.nist.gov\/pubs\/sp\/800\/131\/a\/r2\/final<\/a><\/li>\n
  34. TrueCrypt Foundation, TrueCrypt User Guide. https:\/\/garykessler.net\/library\/crypto\/TrueCrypt%20User%20Guide.pdf<\/a><\/li>\n
  35. BSI, Security Analysis of TrueCrypt. https:\/\/www.bsi.bund.de\/SharedDocs\/Downloads\/EN\/BSI\/Publications\/Studies\/Truecrypt\/Truecrypt.html<\/a><\/li>\n
  36. BSI, Security Analysis of TrueCrypt PDF. https:\/\/www.bsi.bund.de\/SharedDocs\/Downloads\/EN\/BSI\/Publications\/Studies\/Truecrypt\/Truecrypt.pdf?__blob=publicationFilev=2<\/a><\/li>\n
  37. NCC Group, Truecrypt Phase Two Audit Announced. https:\/\/cryptoservices.github.io\/blog\/2015-02-18-truecrypt-phase-two\/<\/a><\/li>\n
  38. man7.org, cryptsetup-tcryptDump(8). https:\/\/man7.org\/linux\/man-pages\/man8\/cryptsetup-tcryptDump.8.html<\/a><\/li>\n
  39. id774, \u672a\u6765\u306e\u81ea\u5206\u306b\u610f\u5473\u3092\u6b8b\u3059\uff082026-05-12\uff09. https:\/\/blog.id774.net\/entry\/2026\/05\/12\/4750\/<\/a><\/li>\n
  40. id774, \u30d0\u30c3\u30af\u30a2\u30c3\u30d7\u30fb\u30ea\u30ab\u30d0\u30ea\u30fc\u6226\u7565\u306b\u304a\u3051\u308b\u7269\u7406\u5a92\u4f53\u7ba1\u7406\uff082026-05-10\uff09. https:\/\/blog.id774.net\/entry\/2026\/05\/10\/4743\/<\/a><\/li>\n
  41. id774, LUKS \u6697\u53f7\u5316\u306e\u624b\u9806\u3068\u904b\u7528\uff082026-05-11\uff09. https:\/\/blog.id774.net\/entry\/2026\/05\/11\/4746\/<\/a><\/li>\n
  42. id774, TrueCrypt \u8cc7\u7523\u3092 GNU\/Linux \u3067\u4fdd\u5168\u3059\u308b\uff082026-05-16\uff09. https:\/\/blog.id774.net\/entry\/2026\/05\/16\/4773\/<\/a><\/li>\n
  43. id774, \u6697\u53f7\u5316\u30c7\u30a3\u30b9\u30af\u904b\u7528\u624b\u9806\u3092\u6574\u7406\u3059\u308b\uff082026-05-31\uff09. https:\/\/blog.id774.net\/entry\/2026\/05\/31\/4829\/<\/a><\/li>\n
  44. id774, \u81ea\u7531\u30bd\u30d5\u30c8\u30a6\u30a7\u30a2\u3060\u3051\u3067\u6697\u53f7\u5316\u5a92\u4f53\u3092\u3069\u3053\u307e\u3067\u6271\u3048\u308b\u304b\uff082026-06-03\uff09. https:\/\/blog.id774.net\/entry\/2026\/06\/03\/4849\/<\/a><\/li>\n
  45. id774, \u6697\u53f7\u306f\u3044\u305a\u308c\u7834\u3089\u308c\u308b\uff082026-06-01\uff09. https:\/\/blog.id774.net\/entry\/2026\/06\/01\/4831\/<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    Operating an encrypted disk is not a task that ends when luksFormat succeeds. A LUKS device may look correct i … \u7d9a\u304d\u3092\u8aad\u3080<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[33,27,31,14],"tags":[],"class_list":["post-4864","post","type-post","status-publish","format-standard","hentry","category-cryptography","category-english","category-resilience","category-tech"],"_links":{"self":[{"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/posts\/4864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/comments?post=4864"}],"version-history":[{"count":1,"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/posts\/4864\/revisions"}],"predecessor-version":[{"id":4865,"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/posts\/4864\/revisions\/4865"}],"wp:attachment":[{"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/media?parent=4864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/categories?post=4864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.id774.net\/entry\/wp-json\/wp\/v2\/tags?post=4864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}