That model’s got an html5 console available so I don’t have to mess with Java. The one thing I haven’t got it to do is remote power cycle. I make a point to set up wake on LAN for that.
The way I’ve ended up going is to just use a standard keyboard and monitor with a KVM over IP switch. In the US it’s not hard to find relatively inexpensive ones on the used market, but they do require a module for each computer, which can increase the costs. I’ve had good luck finding the Avocent MPU2016 switches. Worth a look on eBay anyway.
Since you’re new to this and therefore probably haven’t set up too much infrastructure yet, let me put in a plug for ZFS for the file system underlying your data. That will unlock for you snapshots and the ability to send very efficient backups off site to another ZFS pool.
There are commercial offerings for all this (I think rsync.net will give you a ZFS target), but I essentially have a second NAS set up at another location for the purpose.
Beyond that, I’m also a big fan of BackBlaze B2, which can give you object-based online storage.
As far as what to back up, that’ll depend on your setup. I usually find it simplest to backup my entire VM and do recovery by restoring the VM.
Right now I don’t think you need to do anything special. Unless you did something out of the ordinary, Tailscale didn’t put your computers directly on the internet. What it did was create what’s called an overlay network that allows devices connected to that network to talk to each other. It’s private and encrypted and random folks on the internet can’t get on it by default.
Do learn some networking (there are tons of great YouTube channels, books, and podcast that can help), but right now you can afford to do that slowly and not try to rush to complicate your setup before you understand it. There’s so much material out there, but I found this particularly useful to get an overview when I was first learning: https://www.grc.com/sn/sn-309.pdf.
A bad route would be the first thing I’d check, too.
It sounds like u/transientpunk@sh.itjust.works is already pretty familiar with the Linux command line, but just in case, you can check the routing table (on both the NAS and the client machine) with ip route
(that should show the whole routing table) and get the specific route to the remote device with ip route get 10.42.69.XXX
(change the XXX to make it the address of the remote system). If either side shows that the route is going over your default gateway, that’s your problem.
I haven’t noticed anyone else bring it up, but you mentioned in passing the possibility of using a RAID 0. I’d avoid that except in very specific circumstances. They’re potentially fine for a scratch disk type of scenario, but if any member of the array fails, the whole array is toast. The chances of a failure increases with was each disk added, so a RAID 0 is less reliable than a single disk. I definitely wouldn’t want to trust my family’s photos to it.
Your setup is actually very similar to mine at home, except that I’m running pfSense on a used thin client with a quad-port NIC. I agree the UniFi switches and APs have never given me a problem.
This promises to be a fun project!
It sounds to me like you have above-average demands on your network and I’d agree that UniFi (and therefore probably Omada) are not what I’d consider great as routers/firewalls.
I’m a fan of pfSense/OPNSense for that purpose, which you can install on pretty much any x86_64 hardware. They’re both wonderful and you can fine tune to your heart’s content or get them set the way you like and leave them.
If you really like a dedicated router appliance, I do like the Mikrotiks, too, but you’d have to study their sometimes-peculiar way of doing things.
To my tastes, UniFi does great at switching and wireless, but any of you’re unhappy with that direction, I’ve heard good things about Omada and the Aruba stuff is fantastic. I recently have been playing with some used iap-325s from eBay. I picked them up for $25 and they’ve been terrific.
I think what you’re describing can be accomplished with docker-compose’s depends_on option. I’m not certain how it works across compose files, but that would be the first place I’d look.
I’d just give it time. Let the account sit unused and set any messages to be forwarded to your new account. If you don’t notice anything in the next year or so, you probably won’t miss anything that might still be linked.