Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
I don't. Of my 120tb, I only care about the 4tb of personal data and I push that to a cloud backup. The rest can just be downloaded again.
Do you have logs or software that keeps track of what you need to redownload? A big stress for me with that method is remembering or keeping track of what is lost when I and software can't even see the filesystem anymore.
I don't know of a pre-wrapped utility to do that, but assuming that this is a Linux system, here's a simple bash script that'd do it.
That'll drop a text file at
/tmp/storage-history/files.txtwith a list of the files at that location, and create a git repo at/tmp/storage-historythat will contain a history of that file.When your drive array kerplodes or something, your files.txt file will probably become empty if the mount goes away, but you'll have a git repository containing a full history of your list of files, so you can go back to a list of the files there as they existed at any historical date.
Run that script nightly out of your crontab or something (
$ crontab -eto edit your crontab).As the script says, you need to choose a file_list_location (not
/tmp, since that'll be wiped on reboot), and set path_to_monitor to wherever the tree of files is that you want to keep track of (like,/mnt/file_arrayor whatever).You could save a bit of space by adding a line at the end to remove the current files.txt after generating the current git commit if you want. The next run will just regenerate
files.txtanyway, and you can just usegitto regenerate a copy of the file at for any historical day you want. If you're not familiar withgit,$ git logto find the hashref for a given day,$ git checkout <hashref>to move where things were on that day.EDIT: Moved the
git checkoutup.That's incredibly helpful and informative, a great read. Thanks so much!
Abefinder/Neofinder is great for cataloging but it costs money. If you do a limited backup it's good to know what you had. I use tape formatted to LTFS and Neofind both the source and the finished tape.
If you can't remember what you lost, did you really need it to begin with?
Unless it's personal memories of course.
I can't remember the name of an excel spreadsheet I created years ago, which has continually matured with lots of changes. I often have to search for it of the many I have for different purposes.
Trusting your memory is a naive, amateur approach.
If the spreadsheet is important it sounds like it would be part of the 4 GB that was backed up.
The key here being that you actually remember the file exists, because it's important. Some other random spreadsheet you don't even remember exists because you haven't needed it since forever is probably not all that important to backup.
If you loose something without ever realizing you lost it, it was not important so there would be no reason to make a backup.
Psst, you missed the point and need to re-read the thread.
You put that with everything else similar into a folder, which is backed up. Mine is called "Files". If there's something in there that I don't need backed up. It still gets backed up. If there's something very large in there that I don't need backed up, it gets removed in one of my "oh shit these backups are huge" purges.
So you do remember that you have several frequently-used spreadsheets.
For me, I have a bad memory. I might remember a childhood movie (a nickname I give to special Linux ISOs) that I hadn't even thought of for 10 years and track down a copy, sometimes excavating obscure sources, and that may be hours of one-time inspiration and work repeated many times over. Having a complete list is a good helper, but a full backup of course is best.
In my case, for Linux ISOs, is only needed to login in my usual private trackers and re-download my leeched torrents. For more niche content, like old school TV shows in local language, I would rely in the community. For even more niche content, like tankoubons only available at the time on DD services, I have a specific job but also relying in the same back up provider that I'm using for personal data.
Also, as it's important to remind to everyone, you must encrypt your backup no matter where you store it.
My *arrstack DBs are part of my backed up portion, so they'll remember what I have downloaded in my non-backed up portion.
That's a great point.
servarr* and jellyfin are managing my movies and tv-shows
Set up a job to write the file names of everything in your file system to a text file and make sure that text file gets backed up. I did that on my Unraid server for years in lieu of fully backing up the whole array.
That should be part of the backup configuration. You select in the backup tool of choice what you backup. When you poose your array then you download that stuff again?