For proper backups, backup to a local external disk (e.g. a time capsule or NAS) and an externally with incremental backups (e.g. Arq, Backblaze, tarsnap).
I use Arq, and the nice thing (in contrast to my Time Machine backups) data is also backed up on the go.
Is a backup really a backup if it's onsite? You don't want a fire to take out your PC and external disk located in the same house.
However if it's a choice between onsite and offsite backups, which practically speaking it is for most people, definitely offsite wins. The risk of fire, theft, etc. is vastly greater than the risk that Apple has a critical syncing bug and no ability to recover lost data. (Normally they keep deleted files around for 30 days.)
Yes, but it also happens that someone deletes a photo from a stream accidentally and does not realize within 30 days. For this reason, iCloud Photo Stream is not a backup - a backup keeps copies until the end of time.
The "cloud" option itself simplifies the backup process and could potentially reduce the window of a chance for corruption, but it does not eliminate the need for a reliable, local filesystem.
Granted, if your iPhone is offline for extended periods of time, you're also doing it wrong. But maybe you have an iPod Touch instead.
[0] For the last few years, the newest iPhone is the #1 most common camera model found in EXIF data on Flickr, http://petapixel.com/2015/01/09/popular-cameras-flickr-2014/. IIRC, Facebook saw similar results for photo uploads.
That is why a good, well-integrated offsite backup solution that "reduces the window of a chance for corruption" is a much more significant impact on data security than anything we could hope to incrementally improve in the filesystem software layer.
And Apple's solution is even better than you describe. Photos taken from Apple cameras (which are the vast bulk of photos for most customers) are automatically uploaded directly to the cloud as soon as the device joins wifi.
That is the core issue.
Yes, well-integrated offline backup solutions mitigate some aspects of the problem, but when your filesystem can't even guarantee that it did its job correctly, it doesn't matter how well-integrated your "backup" solutions are because the data may already be corrupt.
Nevermind that the "well-integrated" backup solution you are describing here, because of the unreliable filesystem, can't even guarantee that it read the data from disk correctly to a reasonable degree.
This is not some anecdotal "Mac OS X burned me" story -- this is a fundamental, architectural issue. Data loss is real -- and so are my concerns about HFS+.
At this point my guess is he's been running HFS+ without journaling turned on (you can format drives this way) and experienced data loss as a result because the filesystems ability to correct itself was disabled.
This would look like what he's describing.
See John Siracusa's article:
http://en.wikipedia.org/wiki/Data_corruption#SILENT
Same goes for when it reads back the data.
NTFS, ext4, and other consumer-targeted filesystems do not have this feature either, so it's unfair to imply this is somehow specific to HFS+ or Macs. You'd have the same issue on a Windows or Ubuntu install.
https://en.wikipedia.org/wiki/ReFS
So in the near future, Windows will have an answer for the general mainstream, while OS X will be left far behind.
Even ignoring the checksumming issue, HFS+ has known pathologies not only in reliability but in performance compared to NTFS or even ext4 on Linux.
HFS+ is long overdue for replacement.