I recently signed up to a Personal Backblaze cloud backup subscription. The product has some severe limitations: it only runs on Windows, for example; and it takes no notice of -and refuses to back up- anything a Windows PC is connected to via the network. It’s one huge saving grace, however, is that for US$55 per year, you get unlimited backup capacity. If, for example, you plug in a 12TB external hard disk via USB to your Windows PC… that counts as local storage and therefore gets backed up to Blackblaze within the personal backup allowance. Add two more 12TB USB drives to the PC and you’ve just got 36TB of cloud storage for peanuts!
Yes, not working on Linux is a bit of a drawback for someone who stopped using Windows at all in about 2016 (and had spent the 20 years before that trying to!)… but it’s not exactly hard to find an old PC and throw Windows 10 on it and then script something on Linux to push my music collection across to it. Once the music collection has been copied to the Windows PC, it heads off to the cloud, courtesy of Backblaze. I already have six copies of my music collection on various NAS devices and external USB drives. I even have an offline copy, on a pair of disks which only get plugged into a PC once a month for a refresh. But thanks to Backblaze, I now have an offsite backup. You know, for those times when the house catches fire or falls into a sinkhole.
There’s just one small fly in the ointment: my Internet connection is not top-of-the-range stuff. I can upload unlimited quantities of data, but at only around 15Mbps. The music collection is currently at about 1.7TB. Call it 2TB for round numbers’ sake: the online upload time calculator tells me that uploading 2TB at 15Mbps will take 13½ days… which, funnily enough, is pretty much precisely how long it did take!
So, whilst I was able to live with my upload link being pretty much saturated full-time for a fortnight, it’s not something I would want to do repeatedly. One 2TB upload is sufficient until the end of time, thanks very much!
Now: I routinely check my FLAC files are not getting internally corrupt by running my own Absolutely Baching Flac Checker (AFC) against them. To keep the amount of work involved each night minimised, I do one letter of the alphabet each night for 25 nights (I have no composers whose first name starts with a Y!). So today, 1st July, would have been the day to run AFC against all my Aaron Copland, Anton Bruckner and Arvo Pärt (and anyone else whose first name starts with an ‘A’). When it did so, AFC would have written the current date into each of the FLACs it checks, so that in future runs, it will know that *this* file was checked less than 30 days ago, whereas *that* one hasn’t been checked before and the other one over *there* was only checked three months ago for some reason.
The way AFC works like this is generally fine: I’ve scripted its nightly checks of different parts of my music collection for around two years in this way without incident, after all.
But here’s the kicker: AFC writing to a FLAC file updates that FLAC’s timestamp. The file now appears newer than it did, last time it was backed up. So all my differential backup routines will suddenly see several thousand ‘A’ FLAC files become ‘new’ again, and thus include them in tonight’s differential backups to the servers in my loft. That, too, has been something I’ve lived with for two years, because copying 100GB from my PC to the loft over gigabit Ethernet cable isn’t really too much of a problem.
But… you can see the train wreck approaching, can’t you?! If my FLACs are continually being ‘renewed’ by AFC, they will now continually be shipped up to Backblaze, over my anaemic Internet connection… and that definitely is not something I can live with!
For a while now, therefore, I’ve been working on a replacement for AFC which still does the same checks as AFC, but without touching or modifying the FLAC files it checks in any way. Rather than write the date of its checks to the FLAC file, how about storing all the relevant details in a relational database, for example? Then reports on which files are failing the integrity check can be produced at will, simply by querying that database.
And today, I’m releasing exactly that non-intrusive replacement for AFC, called Niente, which gives you all the protections of AFC, but no FLAC file ever looks ‘new’ to differential backup routines, because Niente doesn’t alter the FLAC in any way, shape or form. My one-off Backblaze upload which took so long to complete won’t need to be re-done every month, as it would with AFC. Only genuinely new acquisitions will ever need to trouble Backblaze in the future, so my Internet connection can breathe easy!
Niente is the music dynamic marking for ‘fading away to a whisper’: the intention is that this FLAC check will fade away into the background, without making its presence obvious -and definitely without triggering a ‘backup cascade’ that would permanently clobber my Internet connection! For that same reason, the ‘logo’ or ‘mascot’ for Niente is that other creature which famously faded away, leaving only a trace of a smile behind: the Cheshire Cat. In Niente’s case, the hope is that the residual smile is yours, quietly content in the knowledge that your FLACs are routinely being checked for bit-rot and other internal logical and physical indications of corruption.
Today, then, the Niente product page is live and the software is available to download and install, using the commands:
cd wget https;//absolutelybaching.com/abc_installer bash abc_installer --niente
Simultaneously, the AFC product is withdrawn and can no longer be downloaded or installed. The archive page will still list it and the old versions can still be downloaded manually if you really insisted on it. But there’ll be no more bug fixes or enhancements to it: it’s a dead product and you’re well-advised to leave it be. Niente is where it’s at, and where all future enhancements will show up.