Pi lightweight server with USB SSD instead of powered HDD?

I thought about that but the main purpose is off-site backups by scp so there will be a lot of writing.
--
They do (play, that is), and nobody gets killed, but Metallic K.O. is 
the only rock album I know where you can actually hear hurled beer 
 Click to see the full signature
Reply to
Adam Funk
Loading thread data ...
Or a HDD with its own power supply.
Interesting and weird.
Reply to
Adam Funk
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?
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
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.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
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.
Reply to
A. Dumas
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)
Reply to
A. Dumas
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
Reply to
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.
Reply to
A. Dumas
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.
--
I have a great programming joke but it's only 
funny on my machine.
Reply to
Adam Funk
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.
Reply to
Pancho
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 = 106.1 MB/sec
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?
Reply to
NY
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.
Reply to
Pancho
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
--
W J G
Reply to
Folderol
Aren't we all.
Hmm I think not, Samsung make their own chips while Kingston buy them in from whoever gives the best deal.
--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
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.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
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
Reply to
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.
--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell
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.
--
"In our post-modern world, climate science is not powerful because it is  
true: it is true because it is powerful." 
 Click to see the full signature
Reply to
The Natural Philosopher
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.
[1] Cleaned of data and dirt AFAICT.
--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
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.
Reply to
Pancho

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.