A question in regards to encrypting external Hard Drives

I chose to encrypt my HDD with LUKe at the time of install and I am thinking about doing the same with my backup HDDs as I have the same data on them. Is it a good idea? How safe or reliable is it? I read that I have to wipe out all the data on my drive to do such a thing Protect external storage with this Linux encryption system | Opensource.com. Is there a better option? I use restic too for back up but that is for larger hard drives with multiple version, some drives are small and can only keep one version of the data so I want to back up to them via rsync -auv --delete. What should I do?

Very much depends on what you’re defending against.

If your main system is a(n actually ported) portable device that you can lose or that can get stolen fairly easily then encryption makes some sense for that at least – and if it isn’t it tends to by and large do not. As to your externals pretty much the same: if they leave the house, sure, if not, meh.

You do take some additional risk: an encrypted volume can through physical or other block-level damage become in a practical sense fully undecryptable whereas with unencrypoted data you have way more chances of recovering at least some even if not all. Yet if they are actual backups then the same things holds as for backups generally, i.e., both sources needing to experience an issue at the same time for the data to be in fact gone. So, meh…

What it boils down to is that only you can decide whether or not it makes sense (but I would watch out for leaning towards “makes sense” just because it sounds all cool and stufff).

LUKS enctryption would still count as more or less best and the article you link to seems good. Other options would be e.g. fscrypt to encrypt on the filesystem rather than block-device level. My personal advise would be to not bother with that until you’re confident enough around Linux to deal with potential disasters; LUKS is the well-tested (and fastest) method. Yes, in-place encryption won’t work.

I personally use self-written shell scripts to backup with rsync. The graphical shell grsync around rsync as available from the repositories is slightly higher level and something you may like.

1 Like

Thanks, those were very useful info for me.

Very interesting. I like to know what happens when we encrypt a filesystem. Like how it is going to look like.

In the case of LUKS an entire filesystem is encrypted, in the case of fscrypt the granularity is directories. This will probably help:

https://wiki.archlinux.org/title/Fscrypt

But note then that my preference would for the time being be good ol’ LUKS.

1 Like

So I tried it and I think I blow out my HDD. I used dd count=4096 to wipe out the partition table but now I can’t use cryptsetup luksFormat command to encrypt it, I can’t even open it up with fdisk anymore. I just shows up on lsblk command. What should I do? Did I mess something up?

sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

fdisk: cannot open /dev/sdb: Input/output error

This wouldn’t be intrinsically to do with that dd (more completely as per your own original link with if=/dev/zero and of=/dev/sdb I take it) which should be fine. Have you tried simply eject sdb and unplugging/plugging the drive? How is it connected in any case? USB?

Be very sure by the way to make sure it’s on re-plugging still /dev/sdb.

I did unplug and replug it, still no change. I tried gparted and it says I need to create a partition table. I am looking into these stuff and have not seen before.

image

Ok looks like that fdisk command only is for creating partitions not partition table itself. and there is another cli command by the name of gpart for this. What type Should I choose? Is ms-dos is the same as MBR? What are all those other options? I thought there is only GPT and MBR for this.

Your originally linked article operates in the context of a USB-stick and doesn’t partition it but, yes, normally you’d partition a harddrive.

However, that’s unrelated here: the I/O error you got from fdisk earlier is not going to be other for gparted and it’ll no doubt bum out in the same way once you’d apply. Also would have nothing to do with any of this. No, fdisk is for creation of a partition table indeed.

Yes, “msdos” is MBR but don’t for now concern yourself with this. If fdisk is still giving you an I/O error that needs solving first; I’d reboot and see again.

Ok let me reboot then. I thought since this drive has nothing to do with my OS and is external it is not going to be related to booting. I will try it anyway.

Point is that I’d want a clean slate both as to drive and as to system. But assuming you after reboot still have that I/O error: how is the drive connected? USB? (or eSATA, or …). Does sudo hdparm -I /dev/sdb work? Does it at the end of its output have a Security section? Could you paste that back?

still not working, same I/o error

Also the command you said is not there, should I install it?

❯ sudo hdparm -I /dev/sdb
sudo: hdparm: command not found

Oh, yes, sudo pacman -Syu hdparm

Here is the whole out put, there is security stuff in it too, I hope I have not bricked my HDD using dd :frowning:


❯ sudo hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
        Model Number:       WDC WD10JPVX-22JC3T0
        Serial Number:      WD-WXD1EB3JCR79
        Firmware Revision:  01.01A01
        Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Supported: 9 8 7 6 5
        Likely used: 9
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:  1953525168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      953869 MBytes
        device size with M = 1000*1000:     1000204 MBytes (1000 GB)
        cache/buffer size  = 8192 KBytes
        Nominal Media Rotation Rate: 5400
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, with device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 0
        Advanced power management level: 96
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
                Power-Up In Standby feature set
           *    SET_FEATURES required to spinup after power up
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
           *    Idle-Unload when NCQ is active
           *    NCQ priority information
           *    Host automatic Partial to Slumber transitions
           *    Device automatic Partial to Slumber transitions
           *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
                DMA Setup Auto-Activate optimization
                Device-initiated interface power management
                Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
                unknown 206[12] (vendor specific)
                unknown 206[13] (vendor specific)
                unknown 206[14] (vendor specific)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        190min for SECURITY ERASE UNIT. 190min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50014ee6aef78946
        NAA             : 5
        IEEE OUI        : 0014ee
        Unique ID       : 6aef78946
Checksum: correct

You’d as far as I know through many USB-bridges in fact see an indication of said bridge in the model strings which I’m not seeing there so just to be very, very sure: that seems to be a 1T Western Digital 2.5" SATA drive. Are you sure you’re looking at the right drive? Is this your external? And once again, if, yes, how is it connected?

Yes I am sure it is it, I have on internal HDD and one External SSD connected to it via USB. I used it daily to backup my data without a problem.

Weird I did it via Gparted and it actually worked. Now I can do all kinds of things with it like normal. And I can open it via fdisk now.

Well, okay then; my next suggestion is going to be to firmware-level erase that drive and wanted to as such make really sure I wouldn’t be instructing you to erase a system drive…

First: no, that dd really can not have done anything bad as such, although it seems to have laid bare an issue with the drive. So let us fully reinitialize it. As the above hdparm output says, this will take some 190 minutes, i.e., 3 hours+. Make sure to be plugged in if this is a laptop; don’t want to run out of battery halfway through.

You do:

$ sudo hdparm --security-set-pass foo /dev/sdb
$ sudo hdparm --security-erase foo /dev/sdb

If the first command errors out that would be unfortunate; if not, the second will take approx 190 minutes to return you to the prompt.

When it does you have that drive as “factory-reset” as possible. You should then be able to with e.g. sudo fdisk /dev/sdb or gparted or whatever you feel like first create a partition table (which, yes, is on an HDD better than working directly on the device itself as per that article).

Did not see your second message before posting; okay, no need then for the long erase.

Ok, any idea what happened there and why? i suppose if I run the same commands there is going to get into the same trouble.