There’s no authoritative list of instances since federation isn’t required, but tools like lemmyverse.net will give you a solid list of the ones discoverable from the most well known federations.
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 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.
What I do is on the originator drive, I create new subdirectories and start categorizing items by content; like I'll put all the ebooks into one directory, and all the television into another. It just makes it easier for me to find things later if I can just head to the drive with all the television on it.
If there's a particular directory with a lot of content, I might create further divisions - maybe shows that are finished vs those who are still getting new episodes, or sitcoms vs drama, that kind of thing.
Then I make a list of how big each master directory is, and I start copying them over to the most appropriate-sized drive. I usually find that I can fit in one large directory, and a couple of smaller ones, and then the last drive gets all the leftovers. I also tape a post-it note to each drive saying something like "2022-23 television" or "science fiction audiobooks" or whatever.
I also create a new directory on the originating drive called something like ++COPIED and, once I've copied content to a new drive, I move the original directory to ++COPIED: I'll still have access if I need it, but I don't have to keep track of it any longer. Once everything is successfully copied over, I can just delete that one directory.
It's a manual process, yes, but it does make it easier for me to find stuff when I want to look at it again later.
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.
The Playapod website mentions a web player, does the web player happen to sync with your app on the phone? If so maybe you can extract it through the web player on a desktop.
According to this you can copy stuff onto it. I assume you’ve tried to see if you can copy off? If not, then there is probably no way to extract the audio, short of recording it as it plays.
This helped me, thank you so much! I filtered by .mp3 and I’m using DownThemAll to download all the episodes in batches.
ETA at first, all the downloads failed because I was attempting to download multiple files simultaneously. After configuring DownThemAll to allow only one simultaneous download, it’s been smooth sailing.
A mirror array is not a backup. So therefor I would use at least one of those extra drives for a weekly backup of your data. You want some sort of not real-time backup in case you get cryptoed for example
What if the cloud server corrupts your data in transfer or worse shuts down its server without notification. It can and has happened.
For example, I had a cloud backup went to get it and the server could no longer be found. That was with Dropbox mind you. I lost 10gb of important files because of it. Never trust just one source of backup. Always have a secondary just in case.
datahoarder
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.