Pi lightweight server with USB SSD instead of powered HDD?

Or a HDD with its own power supply.

Interesting and weird.

Agreed. So an interesting decision between HDD and SSD! Some SSDs do have a write-limit specified, although my first reaction would be if it's off-site and over the network perhaps SSD might be the better choice. Are you allowing incremental backups, or full backup each time?

Have you thought about doing anything to minimise backup write/delete volumes, i.e. using rsync or rsnapshot to do the backups?

Both back up only new or changed files and remove erased files from the backup media. The difference is that rsync maintains a backup copy of the files on the disk as it stands while rsnapshot keeps track of the disk as it was over a period of days and weeks, using symlinks so that unchanging files only have a single copy on the backup disk.

The speed is nice: when I made compressed backups using tar the nightly backup took 3-4 hours: switching to rsnapshot has brought this down to 9 minutes a night and I can now look back across 4 weeks worth of backups compared with 13 days for zipped tar files - on the same computer and backup volume.

In this case my choice would be a HDD because the latency and throughput are almost certainly limited by the network, not the drive, and a HDD is still quite a bit cheaper than an SSD. Or maybe you could go for an enterprise grade storage HDD for the same money (I think the consumer versions of HDD and SSD are about equally reliable).

That's another thing, and like Martin said, I would strongly suggest switching from scp to rsync at least, maybe rsnapshot. Much more reliable transfer and potentially MUCH less volume.

Basic example without versioning, just one backup of existing files: "rsync -auv /my/dir server:" which requires pre-configured (and tested, so the client doesn't stall with "Add unknown key?") SSH access. This copies "dir" and all its contents to the SSH root of server, preserving all attributes, only transferring updated files.

Oh, that was muscle memory, but obviously don't use the -v option for unattended transfers. Instead, there's a -q option and you could redirect any output: [command] &>/dev/null (or the error output to a file, etc)

The latency of a network filing system is still orders of magnitude better than a hard disc, and with true gigabit Ethernet on the Pi 4, it just about matches the throughput of a USB3 attached hard disc. Plus you don't have to wait for the disc to spin up on your first access.

I don't think you'd gain anything on a Pi from that.

---druck

That may be true but I guess you're thinking LAN. He said off-site, so I was thinking over the internet and who knows how many hops.

I should have written "over ssh" rather than "by scp" --- I use `rsync

-e ssh ...` for some things (directories of stuff) and `scp ...` for others (small number of .tar.gz files).

I haven't used rsnapshot before but it looks useful; thanks for the pointer.

A quick look at my rpi4 USB SSD says network speeds are barely just over half local speeds, Network read speed is 118MB/s, local buffered is 224 MB/s (from sudo hdparm -Tt /dev/sdb)

I suspect an SSD is more durable than a HDD too (time will tell). HDDs are cheaper and may be less susceptible to total catastrophic data loss.

An RPI4 USB SSD combination is a workable NAS solution.

Is it the case that "an SSD is more durable than a HDD", given the finite lifetime of the NAND gates to repeated changes of state? AFAIK the magnetism of an HDD does not have a finite number of changes after which the error rate starts to increase, although it *does* have moving parts (head arm and spinning platters). I suppose wear-levelling firmware in the SSD tends to mitigate the finite-write limit a bit.

Would you recommend a USB SSD for something like a PVR where very large files are frequently being written, erased and new files written. Is the finite-write thing less of an issue than it used to be?

I've just tried a copy of a large file between Windows and Pi over SMB share and gigabit Ethernet.

hdparm gives:

cached reads 750.02 MB/sec buffered reads 75.54 MB/sec

copying Windows to Pi (writing to Pi) 1,389,566,656 in 52.9 seconds = 26.3 MB/sec

copying Pi to Windows (reading from Pi) 1,389,566,656 in 13.1 seconds =

Both transfers initiated from the Windows computer. I'm not sure how to make a Pi connect to a Windows SMB share - I always get permission problems to establish the initial SMB session, before actual file read/write begins.

The writing is roughly 1/4 of the theoretical LAN rate; the reading is pretty much 100% gigabit speed, as shown by the Windows Task Manager | Networking graph.

Hold on a mo... my "copying Pi to Windows (reading from Pi)" is faster than hdparm's buffered read figure which is the one which tests real disk reads as opposed to cached ones of CPU, RAM and HDD cache but not physical read. Can anyone explain this?

I'm just a guy on the internet, but My 500GB Samsung EVO 850 has an endurance 150 TBW. Assuming 10 year life span that is about 40 GB write a day.

After 5+ years I'm at GB Written: 41,704.488. So not even a third used up.

write app I'd be temped to use this disk as disposable. But most PVRs don't use that much. My security camera is only 20GB a day.

Not sure buffered reads are actual real, as opposed to only using a small buffer and hence almost real disk reads.

Is the file in the cache, i.e pick a file you know isn't. My Pi is using about 3GB of its RAM as a file cache.

Make sure you're doing a sync before reading the time. It's quite possible to get a return before a single file has *actually* been transferred

Aren't we all.

Hmm I think not, Samsung make their own chips while Kingston buy them in from whoever gives the best deal.

The SSD may bounce better if dropped.

What you're using the device for is also important: for longish term 'cold' storage the HDD (and maybe an SD card) is preferable to an SSD, simply because an unpowered SSD can lose data: a bog standard SSD may start up loose data after 10 months or so unplugged while an enterprize device may start to loose date after 1-2 months. This detail is in the Industry Standards specs, so you can go and look them upts in the specs, so you can look it up...

Would you recommend a USB SSD for something like a PVR where very large

I suspect this depends. You certainly wouldn't use a shingled HDD that way: it would be deathly slow, while it may be a good idea to use a good quality drive (think WD black) because although that class of drive will be slower than an SSD it will also be cheaper as well as quite possible lasting longer.

Yes, this is ideal for flash storage, it's all large sequential writes, and very infrequently in computer terms.

The flash killer is almost constant small random access writes, as occurs when an SSD is used as the main storage medium for a computer, such as the Pi 4, but worse still Windows.

---druck

I?ve had one SSD fail in the last 10 years (and that was an OCZ), I?ve lost count of how many HDDs I?ve had fail in the same interval.

I am not so sure.

Hard failure of the outboard electronics will cripple both, the only advantage of an HDD is that you can, in extremis, fit a new drive board from an identical unit to recover data.

As far as the memory storage medium goes both will remap bad sections out and both will report pending failure via SMART

interrogating my units with smartctl reveals that their projected life exceeds my average hard drive life: In short SSDs are now better than HDDs in every respect except price

Very much so.

Yep, so when HDDs are good enough (including lifespan) use them otherwise pay the price for the better product.

Personally I go for 'refurbished'[1] ex data centre 3.5" SAS drives for bulk data. They're dirt cheap and tend to have nearly idled for three years before being replaced because of age so for all practical purposes they're nearly new and plenty fast enough until the network goes to 10gig, not soon at today's prices!

For anything else SSDs rule the roost, NVMe for best performance and emptiest wallet (only on the work supplied Macbook for me).

For peace of mind about failures use mirrored SSDs, preferably from different manufacturers (say Samsung and Sandisk). After all even good SATA SSDs are cheap, much cheaper than time wasted recovering data or rebuilding systems.

In the past 12 years I have had 4 SSD failures: OCZ Vertex 60, OCZ Vertex 120, OCZ Agility 120, OCZ Vertex 240.

Fortunately, I only bought 4 OCZ drives. All my other SSDs are still in use, in some capacity or another.