• 0 Posts
  • 24 Comments
Joined 1 year ago
cake
Cake day: June 30th, 2023

help-circle



  • OS: NixOS (high learning curve but its been worth it). Nix (the config language) is a functional programming language, so it can be difficult to grok. Documentation is shit as its evolved while maintaining backwards compatibility. If you use the new stuff (Nix Flakes) you have to figure what’s old and likely not applicable (channels or w/e).

    BYOD: Just using LVM. All volumes are mirrored across several drives of different sizes. Some HDD volumes have an SSD cache layer on top (e.g., monero node). Some are just on an SSD (e.g., main system). No drive failures yet so can’t speak to how complex restoring is. All managed through NixOS with https://github.com/nix-community/disko.

    I run stuff on a mix of OCI containers (podman or docker, default is podman which is what I use) and native NixOS containers which use systemd-nspawn.

    The OS itself I don’t back up outside of mirroring. I run an immutable OS (every reboot is like a fresh install). I can redeploy from git so no need to backup. I have some persistent BTRFS volumes mounted where logs, caches, and state go. Don’t backup, but I swap the volume every boot and keep the last 30 days of volumes or a min of at least 10 for debugging.

    I just use rclone for backups with some bash scripts. Devices back up to home lab which backs up to cloud (encrypted with my keys) all using rclone (RoundSync for phone).

    Runs Arrs, Jellyfin, Monero node, Tor entry node, wireguard VPN (to get into network from remote), I2C, Mullvad VPN (default), Proton VPN (torrents with port forwarding use this), DNS (forced over VPN using DoT), PiHole in front of that, three of my WiFi vlans route through either Mulvad, I2C, or Tor. I’ll use TailsOS for anything sensitive. WiFi is just to get to I2C or Onion sites where I’m not worried about my device possibly leaking identity.

    Its pretty low level. Everything is configured in NixOS. No GUIs. If its not configured in nix its wiped next reboot since the OS is immutable. All tracked in git including secrets using SOPS. Every device has its own master key setup on first install. I have a personal master key should I need to reinstall which is tracked outside of git in a password manager.

    Took a solid month to get the initial setup done while learning NixOS. I had a very specific setup of LVM > LUKS encryption /w Secure Boot and Hardware Key > BTRFS. Overkill on security but I geek out on that stuff. Been stable but still tinkering with it a year later.


  • Looks good to me. Interface to Dest Ports are your match conditions. NAT IP/Port are the translations performed on each packet matched inbound and the Dest.

    Traffic going the other way reverses this operation on the Src instead of destination.

    That’s an over simplification of NAT, but for basic port forwarding the general principal holds.


  • Immutable Nixos. My entire server deployment from partitioning to config is stored in git on all my machines.

    Every time I boot all runtime changes are “wiped”, which is really just BTRFS subvolume swapping.

    Persistence is possible, but I’m forced to deal with it otherwise it will get wiped on boot.

    I use LVM for mirrored volumes for local redundancy.

    My persisted volumes are backed up automatically to B2 Backblaze using rclone. I don’t backup everything. Stuff I can download again are skipped for example. I don’t have anything currently that requires putting a process in “maint mode” like a database getting corrupt if I backup while its being written to. When I did, I’d either script gracefully shutting down the process or use any export functionality if the process supported it.


  • I haven’t tested in Windows, but this is my setup Linux to Linux using rclone which the docs say works with Windows.

    Server

    • LUKS
    • LVM
    • Volgroup with a mishmash of drives in a mirror configuration
    • Cache volume with SSD
    • BTRFS /w Snapshots (or ZFS or any other snapshotting FS)
    • (optional) Rclone local “remote” with Crypt if you want runtime encryption at rest and the ability to decrypt files on the server. You can skip this and do client side only if you don’t want the decryption key on the server.
    • SFTP (or any other self-hosted protocol from https://rclone.org/docs/)

    Client

    • Rclone Config /w SFTP (or chosen protocol)
    • (optional) Rclone Config /w Crypt
    • Rclone mount with VFS.

    I use this setup for my local files and a similar setup to my Backblaze B2 off site backups.

    The VFS implementation has been pretty good. You can also manually sync. Their bisync I don’t fully trust though.

    I can access everything through android using https://github.com/newhinton/Round-Sync. Not great for photos though as thumbnails weren’t loading without pulling the whole file last I tested a year ago.




  • One method depends on your storage provider. Rsync may have incremental snapshots, but I haven’t looked because my storage provider has it.

    Sometimes a separate tool like rsnapshot (but probably not rsnapshot itself as I dont think its hard links interact well with rsync) might be used to manage snapshots locally that are then rsynced.

    On to storage providers or back ends. I use B2 Backblaze configured to never delete. When a file changes it uploads the new version and renames the old version with a timestamp and hides it. Rsync has tools to recover the old file versions or delete any history. Again, it only uploads the changed files so its not full snapshots.



  • Important stuff (about 150G) is synced to all my machines and a b2 Backblaze bucket.

    I have a rented seed box for those low seeder torrents.

    The stuff I can download again is only on a mirrored lvm pool with an lvmcache. I don’t have any redundancy for my monerod data which is on an nvme.

    I’m moving towards an immutable OS with 30 days of snapshots. While not the main reason, it does push one to practicing better sync habits.




  • Can try installing Avahi on the RPi (may come on the default image). It will advertise .local over mDNS / DNS-SD. I believe Avahi will advertise on link local if there is no default route to the internet.

    Your system may automatically resolve the domain if its able to pickup the mDNS records to SSH in. Been a couple years since I’ve done it, so I could be forgetting a nuanced detail, but I vaguely remember just ‘plug and play’ if internet for the RPi wasn’t required.


  • My NAS is an mATX mobo with an i5, 64G RAM, 8 disk drives, 3 nvme drives, and an ARC GPU for video transcoding.

    Disk drives are all mirrored. One nvme runs NixOS which is easy enough to redeploy if the drive dies. One nvme is cache on top of the disk drives. Last nvme I use for temp fast storage like Jellyfin transcoding.

    Its more of a combo NAS/server as I run most self hosted apps on it (tor node, monero node, jellyfin, *arr stack, etc).




  • Jellyfin recommends not using SBCs. I was in the same boat as you a month ago. Started on an RPi. Works fine for raw (no transcoding). Poor performance if you do any scrubbing or try to watch something while new content is processing. Got a mini PC. It was better but its basically a laptop chipset, so still not the best experience. Had other things I wanted to do on my self-hosted setup so decided to just bite the bullet and make a proper build: 12th gen i5, Intel Arc GPU, 4+8 SATA ports with PCI card, 3xNVME, 10xHDD/SSD case. Can’t speak to the performance yet. Learning Ansible to automate managing it including installing the OS.

    I would stay away from NAS systems like QNAP or Synology. They tend to not be much better than a SBC.

    For the budget constraints I would just echo getting the cheapest desktop-class PC you can get your hands on in a suitable form factor.

    https://jellyfin.org/docs/general/administration/hardware-acceleration/#hardware-acceleration-on-docker-linux

    While hardware acceleration is supported on Raspberry Pi hardware, it is recommended that Jellyfin NOT be hosted on Raspberry Pis or other SBCs. Many hardware acceleration features are not supported and will fallback to software. In addition, they are generally too slow to provide a good experience when transcoding is needed. Please consider getting a more powerful system to host Jellyfin.