Note that there is some reliability drawback of spinning hard disks on and off repeatedly. maybe unintuitively HDDs that spin constantly can live much longer than those that spend 90% of their time spun down.
This might not be relevant if you use only SSDs, and might never affect you, but it should be mentioned.
This feels like a XY problem. To be able to provide a useful answer to you, we’d need to know what exactly you’re trying to achieve. What goal are you trying to achieve with the VPN and what goal are you trying to achieve by using the client IP?
Note that just because everything is digital doesn’t mean something like that isn’t necessary: If you depend on your service provider to keep all of your records then you will be out of luck once they … stop liking you, go out of business, have a technical malfunction, decide they no longer want to keep any records older than X years, …
So even in a all-digital world I’d still keep all the PDF artifacts in something like that.
And I also second the suggestion of paperless-ngx (even though I’m not using it for very long yet, but it’s working great so far).
Ask yourself what your “job” in the homelab should be: do you want to manage what apps are available or do you want to be a DB admin? Because if you are sharing DB-containers between multiple applications, then you’ve basically signed up to checking the release notes of each release of each involved app closely to check for changes like this.
Treating “immich+postgres+redis+…” as a single unit that you deploy and upgrade together makes everything simpler at the (probably small) cost of requiring some more resources. But even on a 4GB-ram RPi that’s unlikely to become the primary issue soon.
There’s many different ways with different performance tradeoffs. for example for my Homeland server I’ve set it up that I have to enter it every boot, which isn’t often. But I’ve also set it up to run a ssh server so I can enter it remotely.
On my work laptop I simply have to enter it on each boot, but it mostly just goes into suspend.
One could also have the key on a usb stick (or better use a yubikey) and unplug that whenever is reasonable.
Just FYI: the often-cited NIST-800 standard no longer recommends/requires more than a single pass of a fixed pattern to clear magnetic media. See https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-88r1.pdf for the full text. In Appendix A “Guidelines for Media Sanitation” it states:
Overwrite media by using organizationally approved software and perform verification on the
overwritten data. The Clear pattern should be at least a single write pass with a fixed data value,
such as all zeros. Multiple write passes or more complex values may optionally be used.
This is the standard that pretty much birthed the “multiple passes” idea, but modern HDD technology has made that essentially unnecessary (unless you are combating nation-state-sponsored attackers, in which case you should be physically destroying anything anyway, preferably using some high-heat method).
it’s not much use now, but to basically avoid the entire issue just use whole disk encryption the next time. Then it’s basically pre-wiped as soon as you “lose” the encryption key. Then simply deleting the partition table will present the disk as empty and there’s no chance of recovering any prior content.
That saying also means something else (and imo more important): RAID doesn’t protect against accidental or malicious deletion/modification. It only protects against data loss due to hardware fault.
If you delete stuff or overwrite it then RAID will dutifully duplicate/mirror/parity-check that action, but doesn’t let you go back in time.
Thats the same reason why just syncing the data automatically to another target also isn’t the same as a full backup.
That being said: backing up to a single, central, local location and then syncing those backups to some offsite location can actually be very efficient (and avoids having to spread the credentials for whatever off-site storage you use to multiple devices).
“Easy.” You keep using that word, I do not think it means what you think it means.
Sure, but in most of these discussions the ones arguing for “getting rid of copyright” mostly just mean “stop big companies from owning everything”. When mentioning that FOSS licenses depend on copyright to work it’s usually some form of “we’d have to find a way to still make them work …”.
You’re approaching a relevant part (that big corporations have an overwhelming power advantage in this “negotiation”), but “small artists never use copyright law” is just wrong:
Without copyright law they couldn’t even sell their content (or more accurately: they could sell it, but the big corp could simply copy it and sell it better/cheaper due to the economics of scale).
So without copyright the smaller artists would be even more boned than they are right now.
Expert analysis direct to your inbox.
directly below
Saudi Arabia is trying to block a global deal to end fossil fuels, negotiators say
makes me think that maybe I don’t really need that specific offer …
It’s funny how often that argument comes up in FOSS (Free and open source software) circles where people just claim copyright is fundamentally wrong, but at the same time complain when someone violates any FOSS license (all of which depend on copyright to be enforcable).
IMO copyright as a concept makes sense, but it’s duration should be significantly shortened. In todays short-lived world most works lose the majority of their financial value after a few years (let’s say ~10) anyways. So to allow artists to benefit from their creations while still allowing remixing or reasonably recent content I’d say some sane compromise is necessary.
Either that or massively expand (and codify) what qualifies as fair use: let anyone reinterpret anything, but don’t allow verbatim copying.
Simple solutions are not the same thing as easy solutions.
And I guarantee that the majority of it will simply copy todays Mickey Mouse as opposed to the one in steamboat Willie.
But that version isn’t entering the public domain any time soon.
Raid 5 with 3 drives survives one dying disk. Raid 1 (mirroring) with 2 disks survives one dying disk. if either setup loses two disks all the data is gone.
When you run 3 disks then the odds of two failing are higher than if you run 2 disks.
So 3 disks are not significantly safer and might even be worse.
That being said: both setups are fine for home use, because you’ve set up real backups anyway, right?
I’m using encrypted ZFS as the root partition on my server and I’ve (mostly) followed the instructions in point #15 from here: https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html
This starts dropbear as an SSH server that only has a single task: when someone logs in to it they get asked for the decryption key of the root partition.
I suspect that this could be adopted to whatever encryption mechanism you use.
I didn’t follow it exactly, because I didn’t want the “real” SSH host keys of the host to be accessible unencrypted in the initrd, so the “locked host” has a different SSH host key than when it is fully booted, which is preferred for me.
What you describe is true for many file formats, but for most lossy compression systems the “standard” basically only strictly explains how to decode the data and any encoder that produces output that successfully decodes that way is fine.
And the standard defines a collection of “tools” that the encoders can use and how exactly to use, combine and tweak those tools is up to the encoder.
And over time new/better combinations of these tools are found for specific scenarios. That’s how different encoders of the same codec can produce very different output.
As a simple example, almost all video codecs by default describe each frame relative to the previous one (I.e. it describes which parts moved and what new content appeared). There is of course also the option to send a completely new frame, which usually takes up more space. But when one scene cuts to another, then sending a new frame can be much better. A “bad” codec might not have “new scene” detection and still try to “explain the difference” to the previous scene, which can easily take up more space than just sending the entire new frame.