Mergerfs to combine the smaller ones.
this post was submitted on 21 Dec 2023
11 points (92.3% liked)
datahoarder
6729 readers
11 users here now
Who are we?
We are digital librarians. Among us are represented the various reasons to keep data -- legal requirements, competitive requirements, uncertainty of permanence of cloud services, distaste for transmitting your data externally (e.g. government or corporate espionage), cultural and familial archivists, internet collapse preppers, and people who do it themselves so they're sure it's done right. Everyone has their reasons for curating the data they have decided to keep (either forever or For A Damn Long Time). Along the way we have sought out like-minded individuals to exchange strategies, war stories, and cautionary tales of failures.
We are one. We are legion. And we're trying really hard not to forget.
-- 5-4-3-2-1-bang from this thread
founded 4 years ago
MODERATORS
You could create a Python script to do this. There is a library called psutil that would help. Basically,
- iterate over mounted drives and see how much each has available
- based on these values, iterate over your backup files and separate them into chunks that will fit on each drive
- copy chunks to respective drives
Would be a fun little project even for a beginner I think.
I don’t want to do any sort of RAID 0 or striping because the hard drives are old and I don’t want a single one of them failing to make the entire backup unrecoverable.
This will happen in any case unless you had enough capacity for redundancy.
What is in this 4TB drive? A Linux installation? A bunch of user data? Both? What kind of data?
The first step to this is to separate your concerns. If you had e.g. a 20GiB Linux install, 10GiB of loose home files, 1TiB of Movies, 500GiB of photos, 1TiB of games and 500GiB of Music for example, you could back each of those up separately onto separate drives.
Now, it's likely that you'd still have more data of one category than what fits on your largest external drive (movies are a likely candidate).
For this purpose, I use https://git-annex.branchable.com/. It's a beast to get into and set up properly with plenty of footguns attached but it was designed to solve issues like this elegantly.
One of the most important things it does is separate file content from file metadata; making metadata available in all locations ("repos") while data can be present in only a subset, thereby achieving distributed storage. I.e. you could have 4TiB of file contents distributed over a bunch of 500GiB drives but in each one of those repos you'd have the full file tree available (metadata of all files + content of present files) allowing you to manage your files in any place without having all the contents present (or even any). It's quite magical.
Once configured properly, you can simply attach a drive, clone the git repo onto it and then run a git annex sync --content and it'll fill that drive up with as much content as it can or until each "file"'s numcopies or other configured constraints are reached.
sounds like your main limitation is attaching the drives – if you can attach them all to a single system (ex. a separate computer or a NAS case) then at least it becomes somewhat easier to access them all at once
I was thinking JBOD but Wikipedia points out the same issue you mention with RAID 0, failure of one drive can mess up the logical volume which leads to a whole host of new issues to deal with during recovery
Not that big of a deal when it is a backup. Raid is not a backup solution, it is a 24/7 uptime solution. If the main drive dies with JBOD, then you have the backup. If a backup drive fails, then you still have the main. Trick is to ensure any drive issues are dealt with immediately and no backup runs if there is a smart error or similar on any drive.
So having software that monitors drive health and email/notifies you is necessary.
Secondary benefit of JBOD is all drives in a pool are still readable separately.
You could check out git-annex.
This seems like a terrible idea.