When I was a teenager, I was the reason for data loss for my dad, twice. Both times it was because I was re-partitioning a hard drive to install linux.
You would think that taught me a lesson about backups, instead it reminds me every now and again to be grateful for an awesome dad and aspire to handle situations with my kid similarly :)
The first was when the telephone pole outside our house was struck directly by lightning. Not only was it the loudest thing I have ever heard, the current surged through the telephone line, into the internal fax modem, and fries everything within its vicinity. I was 10. I did have backuos, but only only floppy and they didn't cover everything.
The second was storing data in OneDrive - a change to their terms surrounding "lifetime" unlikely noted storage, combined with a client that was unusably slow to download and a deadline for data retrieval meant that I lost most of my files.
The third was SD card failure in digital camera on holiday, the controller chip died catastrophically, leaving the card completely unrecognised. It was a brand new Sony 128GB card, manufactured by Toshiba, and it seemed to be a common issue. I now shoot to two cards simultaneously.
And the fourth time was ... Performing a backup. An errant script deleted the source content, but I'd also deleted the existing backup to free up space for the new backup. I've been weary of using rewritable media for some time now as a consequence, but I think backups themselves are high risk activities.
This made me remember the time during the 90s when I lost all my BASIC programs due to a hard disk crash, and seeing me sitting sad, my mother handed me a bunch of floppies and asked me to see if they contain something useful.
And turned out that it had all the programs! I took the backups and forgot about that. Apparently that is one of the hard things with backups. You need to track them...
I had a similar experience with a Chinese cloud storage provider. They didn't even give a convenient way to export the data. And the client throttled download to like 100KB/s. I luckily was able to parallel download by running the client on several VMs...
> An errant script deleted the source content, but I'd also deleted the existing backup to free up space for the new backup.
Sounds like the backup workflow is fundamentally flawed... But I also have the fear that the backup program with root privileges can go off the rails... So I keep my backup job as simple as just running restic with some systemd restrictions.
So much fail in one single product.
I briefly considered using bluray disks as a backup for my photos and other critical docs. But getting a decent bluray burner seems not so easy these days with most production winding down. Next best thing looks like the "object lock" feature on object store services that prevents deleting objects for a certain time.
In terms of preventing "oops" moments, I'm mainly relying on software (restic) for that, where I trust that (A) backups always append data rather than replacing and (B) it's logic works for marking which data to purge based on rules is accurate. [0]
[0] https://restic.readthedocs.io/en/stable/060_forget.html#remo...
On the other hand, LTO-5 drives are now pretty affordable. And each tape cartridge holds around 2Tb of data for about $20.
I had a smaller setup before, with a simple external LTO-5 drive. Used drives are now are about $300, and you can probably find them cheaper. And LTO-5 is the minimum realistic version, it's the first one that supports LTFS and it has reasonable tape capacity.
Lol, no. "As of today we are closed. Goodbye."
Especially considering what giving even a two weeks now considered "generous".
The probability that the object store goes out of business at the exact time your own copy dies is insignificant.
Or even fancier - just changing the price for the egress.
The probability of a hard drive failure or ransomware at the same time as backblaze or aws going out of business is pretty much not worth thinking about.
The probability of an attacker using the api key in your backup script to destroy the backups is far more possible.
online backup should not be your primary method of backup, you're one billing, identity theft, financial issue, or health issue away from getting your backup nuked
do you have PBS clout? if not good luck https://arstechnica.com/information-technology/2026/08/pbs-s...
It shouldn’t be the only copy of the data that exists.
So I end up with 3 copies of all my photos, on 3 different providers (I mean... 2 different providers plus my homelab disk).
[1] https://immich.app/ [2] https://github.com/garethgeorge/backrest
It's mainly just rsync. When the phone was plugged in, the photos were accessible at a path like "/run/user/1000/gvfs/gphoto2:host=Apple_Inc._iPhone_abc123/".
Now I use Time Machine, but I still need to check whether it includes iCloud photos.
The script currently requires changing one or two folder paths at the top (more details in the script).
A very lovely change over the last 8 years or so lol. I came up in film during the DSLR revolution. 5D2’s/7D’s/Rebels (i series) years.
8bit 420 nasty aliasing recording on single cards and praying baby. Magic lantern booted on those same SD’s!
GPS is useful, but not wifi. I don't need my camera becoming another IOT always online telemetry device. They're one of the few electronic devices built to last. Imagine needing fingerprint unlock on a camera, and for what? Prevent others from viewing your photos? Changing your settings? Also copy from card to pc is the best possible workflow. Imagine cameras like smartphone with no expandable storage.
Stop giving these people ideas! I am now very afraid they will listen to this guy since he actually has a follower base.
pro camera manufacturers are not google or apple. Have we became that defeatist?
So turn off the camera, open the memory card slot cover which is flimsy 1mm prong, eject the card, insert it in the reader (if you have SD reader) or fiddle the microSD first from the convertor and then insert, copy, (insert microSD to SD convertor), open up slot cover, insert the card.
Surely beats just connecting the camera to the WiFi (which it does have anyway) and downloading through SMB. Suuure.
S9900 from 15 years ago had a built-in GPS receiver (and absolutely unneeded and never updated POI system). P1100 needs a smartphone for GPS for whatever reason - and app doesn't work 5 times from 5. But the latter is on me, I knew what I would get when I bought Nikon.
And the rest of it is essentially features for a market that doesn’t exist. People buying cameras today don’t want to send straight to Facebook. They want to sort through raws, edit in Lightroom and then post from a laptop. The market for the features you want all moves to phones long ago.
Sony also has a bunch of the features you are asking for. It can connect to the internet and live sync files to an ftp server. It can even upload proxy videos so your editors can start work before you get back to copy the master copy over. Cameras are sold to prosumers and actual professionals now so the featureset reflects it.
Pretty sure that's the main point of Fuji camera, the output and built it filter is decent enough that you can upload to Social network without any editing.
Btw X100F has Wi-Fi and automated file transfer to PC. But it is faster to transfer it via SD card.
Wifi NAN could be used to solve this problem but I’ve not seen anything using it. Apple only just added support last year though.
We are not in the backup business. We are in the restoration
business.
No. But, well, yes: if you use BE - you will need a restore pretty soon.
I'm the person who actually experienced BE walking around the file server and deleting files. Helpful suuport person had done the needful and said what this is not an issue and it wouldn't be reported as a bug.
[1]: https://github.com/jimsalterjrs/sanoid
[2]: https://du.nkel.dev/blog/2026-05-16_rootless_docker_virtiofs_proxmox/I have an old and loud 16-bay server that boots every 7 days or so if no one is home, `syncoid there here`, and shuts off. I'll get pinged by uptimerobot once in a while if it's overdue and I'll get a notification if a pool is unhealthy or reaching capacity (`sanoid --health` I think). Otherwise I forget I even have it set up.
Automated cold backups are great peace-of-mind.
All my hosts run the same CoreOS setup (https://github.com/ebrahim37/infra-template), where container volumes are placed in one central volumes/ folder and that is the only thing I have to backup.
I plan to implement it like this:
vps1:
- restic container with custom sh entrypoint that will backup volumes/ to homelab every 24 hours
homelab:
- backrest container, to back up volumes/, do prune/check, replicate repo to offsite
- rest-server container, will store backups from vps1, homelab, offsite
offsite:
- restic container, backs up volumes/ to homelab every 24 hours
- rest-server container, store copy of backups from homelab
The deduplication is nice, you can have a snapshot for each week of the past year without crazy storage cost
Your secrets.yaml makes me nervous though - too easy to miss a key and leave something exposed. Why not just add the whole file to the vault?
"So what is the WiFI password here?"
"You sure would to like to know that eh you effing hipster"
"Does that start with a capital Y?"
"Yes"
We finally got a nice setup with CloudNativePG + Barman. This allows for point-in-time restores, but there were a lot of lessons to learn along the way.
- The various types of (database) backups (logical, binary, onsite, offsite, snapshots, write-ahead log...) in combination with the various types of data (database, files, cluster configuration...)
- In our earlier approaches, we tried to preserve the old database volume if it was not corrupt, and use that in our restore. This caused so many complications, because you are fighting the recommended approach. So now, when we need to restore, we always restore from backups and the 'live volume' is dropped.
- For a restore, we just spin up a completely new Kubernetes cluster, instead of trying to restore in-cluster. This is a lot easier.
- Many object stores allow for retention periods, which you can put to good use to prevent malicious or accidental removal of backups. HOWEVER, not all of them are really 'locked'. In some services, you can still override the lock with a forced delete; in others, you can still remove the project holding the storage buckets, which will delete the buckets, and so on... so test those things, instead of just blindly depending on a 'retention period' claim.
- We now automatically run a scheduled restore with verifications on a weekly basis. This requirement does shape your environment, so keep that in mind! There is also the question of how you can reliably and automatically verify that the restore restored the latest data (of a live prod environment). Various solutions exist here, but most are not very elegant!
Honestly, this is only worth it if you are already handling sufficient volume. If you are just starting out, then the easier approach is to just go with a hosted database, which will handle backups and point-in-time restores for you.
This is an empirical claim, but is it grounded in reality?
99% of people don't backup, and that's probably the right choice because the risk is low, they can't meaningfully improve their restoration rate themselves and they don't care enough about their data to classify its loss as catastrophic.
When a person hears someone talk about the importance of backups, but also haven't heard friends/family suffer this date, they will rightfully ignore this warning.
Or do we all follow the best practices as it relates to backups, exercise, sleep, nutrition, accounting, house maintenance, ... Etc.
I do not. Backups aren't near the top of that list.
This stuff just isn't very important to most people and that's okay.
Over 40 years (even with changing disks, upgrading PCs, etc.), the chances of you ending up with your data intact is 0.99^40=0.67. May not seem too bad, but this is just a hardware failure of your main drive we're talking about. When you factor in all the other types of screwups that happen, the annualized failure rate will skyrocket.
So a more conservative version of this quote is that a 20-year old today is very likely to experience data loss over his lifetime.
Thankfully with cloud being ubiquitous at least photos are given one copy in the cloud, but IMO even that is risky. People have different appetites for risk, and that's OK. But over the last 20 years the all of our data has become pretty important. I don't know how many people could stomach the loss of important documents, photos, etc.
It’s still vitally important if you are self hosting your data.
This depends on your viewpoint. Using gmail for example is an implicit backup of your e-mails. Uploading your pictures to Facebook the same. The move from local, private compute and storage to the cloud solved this issue for many to a degree that it is now less important.