Can rsync break a USB pen?

Ubuntu Version:
Ubuntu 24.04.4 LTS

Desktop Environment (if applicable):
Not a GUI related problem

Problem Description:
Dear all,

I’m having a serious problem while using rsync and I can’t tell if I’ve been unlucky enough to found two Kingston USB pens (both are “DT Micro DTMC3G2” formatted FAT32) that are defective in the same way or rsync has something to do with it.

I bought two USB pens, one should be my digital archive and the other its backup (both are formatted FAT32 and protected using BitLocker). I used to backup a couple of times a month the first one on the second one using this script:

--------- my_backup ----------

#!/usr/bin/bash

rsync -aAXv "$1" --exclude={"*no_bak*",".Trash-1000","System Volume Information"} --delete-excluded "$2"

I call this script using the following script:

#!/usr/bin/bash
./my_backup /media/max/ARC/ /media/max/ARC_BAK > $0.log 2>&1

For some months everything worked perfectly then a couple of weeks ago I had a bunch of errors such as:

rsync: [receiver] rename "/media/max/ARC_BAK/10 - Auto/10 - Bolli/.2018-2019.pdf.TpzbgR" -> "10 - Auto/10 - Bolli/2018-2019.pdf": No such file or directory (2)`

Since then the USB pen is dead. I plugged it into several PC (both Linux and Windows) but they don’t react in any way. I got in touch with Kingston support and they sent me a new USB pen.

Today I received the new USB pen.This pen was already formatted FAT32, I protected the new USB pen through BitLocker, using my office Windows PC, and when at home I ran the above script to backup my archive on the new pen.

After a couple of seconds I started having the same error messages and today again the USB pen got broken exactly as the first one: I can plug it in any PC but they don’t react in any way, no USB device is detected.

I’ve made a search on Google to see if there are known bugs in sync that could explain this behavior but didn’t find anything. I had a look at release notes archived on https://download.samba.org/pub/rsync/NEWS but apparently the sync version I’m using is not reported to have such a problem.

It seems quite strange to me that a SW bug could cause a pen to die this way but it also sounds strange to me that two Kingston USB pens have the same problem.

Actually… when I plug in the USB pen something happens, there a line that appears in /dev/disk/by-id:

max@ASUS-V221IC:~$ ls /dev/disk/by-id/usb*
/dev/disk/by-id/usb-13FE_USB_DISK_50X-0:0

however:

max@ASUS-V221IC:~$ sudo dosfsck -v /dev/disk/by-id/usb-13FE_USB_DISK_50X-0:0
fsck.fat 4.2 (2021-01-31)
open: No medium found

Does anybody have any idea about what’s happening and what I could do to solve this issue?

Thanks.

Relevant System Information:
Here are some information on my Linux PC:

HW: https://www.asus.com/supportonly/v221ic/helpdesk/

max@ASUS-V221IC:~$ rsync --version
rsync  version 3.2.7  protocol version 31
Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.
Web site: `[`https://rsync.samba.org/`](https://rsync.samba.org/)
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
    hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs,
    xattrs, optional secluded-args, iconv, prealloc, stop-at, no crtimes
Optimizations:
    SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
    xxh128 xxh3 xxh64 (xxhash) md5 md4 sha1 none
Compress list:
    zstd lz4 zlibx zlib none
Daemon auth list:
    sha512 sha256 sha1 md5 md4
rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
max@ASUS-V221IC:~$ lsb_release  -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.4 LTS
Release:        24.04
Codename:       noble
max@ASUS-V221IC:~$ uname -a
Linux ASUS-V221IC 6.8.0-117-lowlatency #117.1-Ubuntu SMP PREEMPT_DYNAMIC Wed May  6 20:10:37 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
max@ASUS-V221IC:~$ uname -a
Linux ASUS-V221IC 6.8.0-117-lowlatency #117.1-Ubuntu SMP PREEMPT_DYNAMIC Wed May  6 20:10:37 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Screenshots or Error Messages:
See above.

What I’ve Tried:
See above

Ciao,
Max

I wouldn’t use
./ in a script. Use the absolute path instead

Or just put it in a location where it can be found (that’s what $PATH is for), e.g. /usr/local/bin/ (requires sudo) and call it by its basename, without any / in front.

On the actual issue, no bug in any software can cause this. But rsync can have caused high load on the device, maybe even to the point of overheating. Whenever I write an huge amount of data to a pendrive it gets really hot; you may not feel it when touching it on the casing, but unplugging it and touching the USB connector will show you just how hot they can get.


Please put all log and other console/terminal output in pre-formatted code blocks (click the </> icon in the editor first and paste into the new element). Yours are just long lines with inline fixed-size font text, which messes up the line ending an alignment.
It should look like this

#!/usr/bin/bash
./my_backup /media/max/ARC/ /media/max/ARC_BAK > $0.log 2>&1

Sorry for the bad format, the first version of this post was really awful then I noticed there were “##” on many sentences that caused it to be shown in bigger characters. I made some modifications and now it looks better but still not the best post I’ve ever seen.

Overheating actually could be a cause… is there a way to avoid rsync causes such a high load on the device?

EDIT: and now format should have improved even a bit more.

1 Like

I think there are some settings for rate limiting (--bwlimit). BTW, if you still have a rough time and date, you should be able to find it in the system journal (log). I am pretty certain that you are looking for errors of the I/O variety, so we can limit the output:

journalctl -p err --since=<date spec> --until=<date spec>

See the manual of systemd.time for details on the date specification, but you can basically use the same format as that of the timestamps in the journalctl output.

Indeed, it has, considerably so. :clap:

I think this is the interesting part:

mag 22 21:57:29 ASUS-V221IC kernel: device offline error, dev sdc, sector 86144 op 0x1:(WRITE) flags 0x0 phys_seg 2042 prio class 0
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22912, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22913, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22914, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22915, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22916, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22917, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22918, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22919, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22920, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: Buffer I/O error on dev dm-1, logical block 22921, lost async page write
mag 22 21:57:29 ASUS-V221IC kernel: device offline error, dev sdc, sector 88187 op 0x1:(WRITE) flags 0x0 phys_seg 3 prio class 0
mag 22 21:57:29 ASUS-V221IC kernel: device offline error, dev sdc, sector 100736 op 0x1:(WRITE) flags 0x800 phys_seg 3 prio class 0
mag 22 21:57:29 ASUS-V221IC kernel: device offline error, dev sdc, sector 88186 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
mag 22 21:57:29 ASUS-V221IC kernel: scsi 3:0:0:0: rejecting I/O to dead device
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24192) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24193) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24194) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24195) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24196) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24197) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24198) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24199) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24200) failed
mag 22 21:57:29 ASUS-V221IC kernel: FAT-fs (dm-1): Directory bread(block 24201) failed
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 366595)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 366597)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 389122)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 389123)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 389124)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 389125)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 389128)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 389131)
mag 22 21:57:33 ASUS-V221IC kernel: FAT-fs (dm-1): unable to read inode block for updating (i_pos 407556)
[tens of similar lines]

the “–bwlimit” seems something useful when sync works between two servers, it doesn’t sound something for local copies.

Anyway… if I’ve burnt my second USB pen there is little I can do now :frowning:

1 Like

I think so, too.

I’m pretty sure the manual refers to sockets only because of the remote use legacy. Try it. I just did:

rsync --bwlimit=1K /usr/bin/

Take ages to even build the file list.

I think you should have a word with Kingston. Just out of curiosity, is it one of those ultra-high speed USB 3.2 devices? Such throughput needs good cooling, or throttling. But the latter requires extra hardware for monitoring etc., so you connect the dots. :winking_face_with_tongue:

You’re right, I also made some test and the “–bwlimit” also works locally so limiting the speed of the copy can be a workaround (if the cause is the overheating).

Maybe “–bwlimit=500k” could be a good tradeoff between speed and a “stop-burning-USB-pens” policy.

The USB pen is “DT Micro DTMC3G2”.

Ciao,
Max

I think that’d be overdoing it with the throttling. Double digit MiB/s should be the aim, I think.

I think I have one of the older iterations of those. Mine has a pretty solid aluminium case, which should facilitate cooling, but there’s only so much passive airflow can do, I guess. Maybe ask Kingston if they’re interested in a test case to improve their controller.
Or you just got really unlucky and received one from the same batch as the first; sometimes there is a whole batch of defective devices and I have experienced the exact same hardware fault with two consecutive devices in another context; on my next RMA the vendor admitted to having shipped a faulty batch to my local supplier. Or they got a huge faulty batch of flash memory from their ODM supplier.

To confirm, they are dead after performing multiple backups over months!


Looking at the command you provided in your OP, the issue is that you have not specified any default “–delete*” option to delete files that no longer exist in the source image.

Because of that, any files that

  • are deleted the source,
  • have been renamed on the source,       or
  • have been moved to a different directory location than that on the source,

remain as real, but not required copies, on the backup image, thereby creating an unwanted data growth on the USB keys!

You need to specify one of those “–delete*” options to ensure that your backup directory is an exact mirror of your source directory.

If there is no chance of ever coming close to disk limits on your backup disk, you could use the option “–delete-after”, but I strongly recommend you try to reign data growth in by using either “–delete-during”.

I don’t know what others feel about this, but I think the “–delete-before” option is inadvisable for all scenarios except those where it is directly required to achieve some particular disk image configuration “goal”.


One caveat …

If you are creating backup directories (multiple, date-named), then you need a logic to perform a “turnover” of backup images, namely, establish an aging mechanism to purge images that are older than a specified age.


If you are interested, you might want to have a look at my backup script, which is available here:

The behaviour of that script is presented in a posting as part of the following discussion:


Give you a look at my backup drive “high-level” contents, this is a listing:

DB005_F1:
LIMIT__Bandwidth_rsync.txt  lost+found

DB005_F2:
DB001_F2                           Z_backup.DB001_F2.CheckSum.batch     Z_backup.DB001_F2.DateSize.out
KEEP__Z_backup.DB001_F2.err__KEEP  Z_backup.DB001_F2.CheckSum.err       Z_backup.DB001_F2.DateSize.out.PREV
KEEP__Z_backup.DB001_F2.out__KEEP  Z_backup.DB001_F2.CheckSum.out       Z_backup.DB001_F2.err
LIMIT__Bandwidth_rsync.txt         Z_backup.DB001_F2.DateSize.batch     Z_backup.DB001_F2.err.PREV
lost+found                         Z_backup.DB001_F2.DateSize.err
Z_backup.DB001_F2.batch            Z_backup.DB001_F2.DateSize.err.PREV

DB005_F3:
Backup.DB001_F3.tarerr      lost+found                        Z_backup.DB001_F3.DateSize.err
Backup.DB001_F3.tarlog      tarBackup.batch                   Z_backup.DB001_F3.DateSize.err.PREV
DB001_F3                    Z_backup.DB001_F3.batch           Z_backup.DB001_F3.DateSize.out
LIMIT__Bandwidth_rsync.txt  Z_backup.DB001_F3.DateSize.batch  Z_backup.DB001_F3.DateSize.out.PREV

DB005_F4:
DB001_F4                    Z_backup.DB001_F4.DateSize.batch     Z_backup.DB001_F4.DateSize.out.PREV
LIMIT__Bandwidth_rsync.txt  Z_backup.DB001_F4.DateSize.err       Z_backup.DB001_F4.err
lost+found                  Z_backup.DB001_F4.DateSize.err.PREV  Z_backup.DB001_F4.err.PREV
Z_backup.DB001_F4.batch     Z_backup.DB001_F4.DateSize.out

DB005_F5:
DB001_F5                    Z_backup.DB001_F5.batch           Z_backup.DB001_F5.DateSize.err
DB001_F5_Restore.err        Z_backup.DB001_F5.CheckSum.batch  Z_backup.DB001_F5.DateSize.err.PREV
DB001_F5_Restore.log        Z_backup.DB001_F5.CheckSum.err    Z_backup.DB001_F5.DateSize.out
LIMIT__Bandwidth_rsync.txt  Z_backup.DB001_F5.CheckSum.out    Z_backup.DB001_F5.DateSize.out.PREV
lost+found                  Z_backup.DB001_F5.DateSize.batch

DB005_F6:
DB001_F6                    Z_backup.DB001_F6.DateSize.batch     Z_backup.DB001_F6.DateSize.out.PREV
LIMIT__Bandwidth_rsync.txt  Z_backup.DB001_F6.DateSize.err       Z_backup.DB001_F6.err
lost+found                  Z_backup.DB001_F6.DateSize.err.PREV  Z_backup.DB001_F6.err.PREV
Z_backup.DB001_F6.batch     Z_backup.DB001_F6.DateSize.out

DB005_F7:
DB001_F7                    Z_backup.DB001_F7.DateSize.batch     Z_backup.DB001_F7.DateSize.out.PREV
LIMIT__Bandwidth_rsync.txt  Z_backup.DB001_F7.DateSize.err       Z_backup.DB001_F7.err
lost+found                  Z_backup.DB001_F7.DateSize.err.PREV  Z_backup.DB001_F7.err.PREV
Z_backup.DB001_F7.batch     Z_backup.DB001_F7.DateSize.out

DB005_F8:
Appl__Firefox__CachePurge.20220723-225612.001.log  Z_backup.DB001_F1.CheckSum.out
ApplRestore__Firefox.sh                            Z_backup.DB001_F1.DateSize.batch
DB001_F1                                           Z_backup.DB001_F1.DateSize.err
LIMIT__Bandwidth_rsync.txt                         Z_backup.DB001_F1.DateSize.err_FULL
lost+found                                         Z_backup.DB001_F1.DateSize.err.PREV
REF__Z_backup.DB001_F1.DateSize.err__REF           Z_backup.DB001_F1.DateSize.out
Z_backup.DB001_F1.batch                            Z_backup.DB001_F1.DateSize.out_FULL
Z_backup.DB001_F1.CheckSum.batch                   Z_backup.DB001_F1.DateSize.out.PREV
Z_backup.DB001_F1.CheckSum.err                     zzz

Each of those DB005_F? is located at /site/DB005_F?.


The following is an example of the actual “batch” script which runs in the background to perform the backups.

# more Z_backup.DB001_F6.DateSize.batch

	
echo 'Thu 21 May 2026 03:55:17 PM EDT |rsync| Start DB001_F6 
	Process ID => '$$' ...' >&2
	cd /DB001_F6
	
	rm -f /site/Z_backup.DB001_F6.DateSize.out
	rm -f /site/Z_backup.DB001_F6.DateSize.err
	{
	
ionice -c 2 -n 7 rsync 		--bwlimit=32768 		 		 		 		--one-fi
le-system 		--outbuf=Line 		--recursive 		--delete-during 		--preallocate 	
	--links 		--perms 		--times 		--group 		--owner 	
	--atimes 		--devices 		--specials 		--verbose --out-format="%t|%i|%M|%b|%f|"
 		--whole-file 		--human-readable 		--protect-args 		--ignore-errors 	
	--msgs2stderr 		 		./ /site/DB005_F6/DB001_F6/
	
echo 'START = Thu 21 May 2026 03:55:17 PM EDT' ; 
echo '  END = '`date` 
	} 2>/site/Z_backup.DB001_F6.DateSize.err >/site/Z_backup.DB001_F6.DateSize.out
	RC=$?
	
if [ ${RC} -eq 0 ]; then
	
	test -s /site/DB005_F6/Z_backup.DB001_F6.DateSize.out  &&  mv -f /site/DB005_F6/Z_backup.DB001_F6.DateSize.out /
site/DB005_F6/Z_backup.DB001_F6.DateSize.out.PREV
	test -s /site/DB005_F6/Z_backup.DB001_F6.DateSize.err  &&  mv -f /site/DB005_F6/Z_backup.DB001_F6.DateSize.err /
site/DB005_F6/Z_backup.DB001_F6.DateSize.err.PREV
	
	mv /site/Z_backup.DB001_F6.DateSize.out /site/DB005_F6/Z_backup.DB001_F6.DateSize.out
	mv /site/Z_backup.DB001_F6.DateSize.err /site/DB005_F6/Z_backup.DB001_F6.DateSize.err
	
else
	
	mv /site/Z_backup.DB001_F6.DateSize.out /site/DB005_F6/Z_backup.DB001_F6.DateSize.out.$RC
	mv /site/Z_backup.DB001_F6.DateSize.err /site/DB005_F6/Z_backup.DB001_F6.DateSize.err.$RC
	
	man rsync | awk -v P=$RC '{ if( $1 == P ){ print $0 ; } ; }' 
	
fi

@Actionparsnip shared his viewpoint with that statement!

That may be valid for his context. It can also be invalid for your context. You need to make that determination yourself.

My own script uses the command line in the form

rsync ${options} ${relativePathToSource} ${absolutePathToMirror}

which for my context, is the best! You have to test the various approaches to identify which works best for you.


The “–bwlimit” value is supposedly for controlling interface thruput.

In my case, with the system able to collect the source faster than being able to write the backup image, I specify a value to limit the memory buffer size, so that I don’t swamp my memory, slowing down my GUI responsiveness, during the backups which, by the way, is another strategic reason to divide both your main drive and backup drive into multiple partitions, so you can work on one partition while doing backups of another partition which is static. Hence the multiple backup directories listed above.

1 Like

If you look at the script I’ve copied there’s a “delete” option too:

--delete-excluded "$2"

The backup is always an exact copy of the source. Whatever is deleted or renamed in the source is deleted or renamed in the backup too.

Ciao,
Max

I just re-read the man page to be sure. That does not work as a “delete” directive, only as a delete exclusion. Without one of “–delete” or “–delete-WHEN” options, there is no deleting happening.

By itself, “–delete” gives default of “–delete-during”.

So your USB stick is filling up with defunct files, and the fact that you had some partial errors before complete failure is, for me, confirmation of that behaviour.

… and if you don’t want to accept my “interpretation”, you can confirm independantly at the following:

2 Likes

Here are my 2 cents of advice about backup:

I think USB pendrives are not reliable enough for backup purposes.

  • As described by @peterwhite23, overheating can kill a pendrive, and futhermore
  • the memory cells are extremely mass-produced and have a rather short expected lifetime. There is an internal system (in the pendrive) to distribute the write actions between the memory cells to avoid early failure and to redirect write actions from failed cells to ‘extra cells’ (not yet used). The internal system in the pendrive can get overloaded and fail (the logic fails) and all the extra cells can be used …

I would recommend hard disk drives (HDD) or solid state devices (SSD).

2 Likes

I’d never use a USB pen to perform a server backup. I’m pretty sure it’s not the right medium for that purpose.

However, we’re discussing about quite a different situation here. I have one pen where every week I add a couple of files (medical checkups, proofs of purchase, documents from the bank, etc.) and another pen where a couple of times a month I backup the previous pen.

I don’t think that adding a couple of files a week on a pen drive can be considered a stressful operation. The same for the backup pen, where I copy ten files a month. I can’t imagine any use of a media storage that’s less stressful than this.

Regarding the hypothesis that the pen could have been filled up by defunct files, this is also impossible because, as I wrote, I had just received it. The pen was empty when I started the backup yesterday evening. I don’t think that the failure could have been caused by too many files piling up in the pen.

Ciao,
Max

@ericmarceau I read the link you shared, just to understand something more about how rsync works.

That post says:

--delete-excluded tells rsync to not just delete files that are missing at the source but to also delete files at the destination that were excluded from synchronization (--exclude or --exclude-from), regardless if these files would actually exist at the source or not.

“to not just delete files” means that option delete files that are missing at the source and does something more (the “something more” part is deleting files already present on the destination but --excluded in the copy).

So I think my script correctly deletes files from the backup copy when I remove them in the source.

Don’t you agree?

Ciao,
Max

That section was poorly phrased. I tried to find another reference that spells it out as clearly, without success. So, in a moment of weakness, I entered the following string in Google Search:

linux rsync using no other delete flags, does "--delete-excluded" delete files other than under the specified directory

Response offered by Google AI

AI Overview

No, the --delete-excluded flag only deletes files and directories located under the specified destination directory.

It does not impact files outside the target path of the rsync command. [1]

How it Works

When you use --delete-excluded, rsync applies your exclude rules to the destination. If a file or folder exists at the destination but matches an exclude pattern, rsync will remove it even if it is still present at the source.

  • Scope: It only scans and acts upon the “receiving side” directories that are actively being synchronized.

  • Interaction with --delete: While --delete removes files that no longer exist at the source, it typically protects files that you have explicitly excluded. Adding --delete-excluded overrides this protection, forcing the removal of any destination files matching your exclude list.


That explanation is how I understand the separation of scope between

  • group 1 { --del | --delete | --delete-before | --delete-during | --delete-delay | --delete-after }      

and

  • group 2 { --delete-excluded } ,

where this last is in a group of its own for actions that act on a file grouping which is exclusively outside the scope of the intended search tree(s).

1 Like

You can test your rsync command with -n (dry run), with verbosity -v to see if you are getting the desired result before making it permanent. Trial use of rsync can lead to unintended results, including wiping a disk.

For external backups, I prefer a SSD or HDD in an enclosure.

2 Likes