I've done exactly that to a couple of transcend usb sticks and managed to kill one when deleting some files while the rsync was running (to free up enough space

I've done exactly that to a couple of transcend usb sticks and managed to kill one when deleting some files while the rsync was running (to free up enough space for the rsync to finish). I think the controllers on the sticks are just not as good as SSDs. At least it was an obvious problem (drive completely unresponsive after that), but I wouldn't make that your only copy. The main thing I have been doing is using old hard drives, each in an inexpensive case[0] that can easily be attached to a usb to SATA/IDE adaptor[1] (there are others to consider if you don't have IDE drives, but that one seems to work well and not all of them do; for SATA only look at UASP). You might think that old drives are more likely to die randomly, but I haven't had that happen once yet (good to keep a couple of copies of stuff you care about). [0] https://www.fasttech.com/p/1645000 https://www.fasttech.com/p/1645000 [1] https://www.fasttech.com/p/8292100 https://www.fasttech.com/p/8292100 I sometimes use rsync but also have an archive script that a) runs mtree with sha512 per file and leaves the file in the directory being archived, b) creates a .tar.xz with SHA256 checksum in the xz (except for already compressed stuff, then I either rsync or use gzip with a seperate SHA256 sum), and c) encrypts most things via scrypt -t 5 before hitting unencrypted external disk (ext2 with limited features for maximum portability). Not exactly push a button level convenience but it works ok for me. If you just use basic rsync you can end up copying corrupted files from your system over the backup before noticing that they are corrupted. I think there are various ways to avoid this, so far I just have multiple copies that I update at different times but there are likely better ways. Tarsnap seems like a good option for stuff you wouldn't want to loose in a fire, but I haven't used it so far.