this post was submitted on 08 May 2025
62 points (95.6% liked)
Linux
54028 readers
1501 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
That's the thing: it doesn't need to be. If your backup software or filesystem supports block-level deduplication, all matching data only gets stored once, and filenames don't matter. The files don't even have to 100% match. You'll still see all your files when browsing, but the system is transparently making sure to only store stuff once.
Some examples of popular backup software that does this are Borgbackup and Restic, while filesystems that can do this include BTRFS and ZFS.
I guess you're missing the point then. I'm backing up data coming from many different file systems, FAT12, FAT16, FAT32, EXFAT, NTFS, HPFS, EXT2, 3 and 4, ISOs (of varying degrees of copy protection plus MODE1 and MODE2 discs with audio tracks)...
Plus different date revisions of many files.
You think there's anything consistent enough where any one solution works?
I need all the recommended software I can throw at it. Sure I'd love a purely automated solution, but i know there's still gonna be a lot of manual curating on my part as well.
Also, files don't have to match and filenames aren't important? Are you a psychopath? That's exactly what I want, to organize folder and filenames, and match and remove duplicates based on file hashes.
Either I'm massively misunderstanding why it is you want to curate your backup by hand, or you're missing the point of block-level deduplication. Shrug, either is possible.
I get the concept of block level reduplication, no problem.
But some of these drives came from friends that reorganized their copy of files their own way, while I took my main branch they copied from and salvaged damaged files.
Ever heard of goodtools? I've spent an awful lot of time salvaging corrupt video game console ROMs. I have all of Atari 2600, most of NES and SNES, a number of N64 and a number of PSP games, along with a lot of other stuff.
I ain't about to play headgames on what I have and haven't salvaged already, I must keep track of what device stores what, what filename is what, and what dates are what.
I want an organized file/folder structure. I didn't spend the past 20+ years to trust everything to automation.
This is precisely the headache I'm trying to save to you from: micromanaging what you store for the purpose of saving storage space. Store it all, store every version of every file on the same filesystem, or throw it into the same backup system (one that supports block-level deduplication), and you won't be wasting any space and you get to keep your organized file structure.
Ultimately, what we're talking about is storing files, right? And your goal is to now keep files from these old systems in some kind of unified modern system, right? Okay, then. All disks store files as blocks, and with block-level dedup, a common block of data that appears in multiple files only gets stored once, and if you have more than one copy of the file, the difference between the versions (if there is any) gets stored as a diff. The stuff you said about filenames, modified dates and what ancient filesystem it was originally stored on... sorry, none of that is relevant.
When you browse your new, consolidated collection, you'll see all the original folders and files. If two copies of a file happen to contain all the same data, the incremental storage needed to store the second copy is ~0. If you have two copies of the same file, but one was stored by your friend and 10% of it got corrupted before the sent it back to you, storing that second copy only costs you ~10% in extra storage. If you have historical versions of a file that was modified in 1986, 1992 and 2005 that lived on a different OS each time, what it costs to store each copy is just the difference.
I must reiterate that block-level deduplication doesn't care what files the common data resides in, if it's on the same filesystem it gets deduplcated. This means you can store all the files you have, keep them all in their original contexts (folder structure), without wasting space storing any common parts of any files more than once.
Also, try converting Big Endian vs Little Endian ROM file formats. I spent many months doing that, via goodtools.
I'm not in any hurry to accidentally overwrite a ROM that's been corrected for consistency in my archives because some automatic sync software might think they're supposed to be the same file.
Block level dedupe doesn't account for random data at the end of the last block. I want a byte for byte hash level and folder comparison, with the file slack space nulled out. I also want to consolidate all related files into logically organized folders, not just a bunch of random folders titled '20250505 Backup Turd'
I also have numerous drives with similar folder structures, some just minimalized to fit smaller drives. I also have archives from friends, based on the original structure from like 10 years ago, but their file system structures have varied from mine over the years.
If you want to be that particular about your system, you'd be best off just writing your own.
Bro is thick. He just wants to hear sorry bro, can't be done to justify the fact that he'll be doing this by hand, because he wants to.
Thank you, at least someone understands my stubbornness. 👍
Don't put it past me, I already have before.