3 ms·

Why tarsnap when wasabi or backblaze would be significantly cheaper? You can just encrypt by yourselves anyway. Also I run my own personal infra and here’s wha

by isatty 5y ago

Why tarsnap when wasabi or backblaze would be significantly cheaper? You can just encrypt by yourselves anyway. Also I run my own personal infra and here’s what I do: * treat servers as cattle, not pets. This is really important. Have mandatory reboots, never be afraid of reboots. * preferably do things with an automation method, I use ansible for n=5 but pick whatever you like * have SOME monitoring. It’s not too hard to throw up prom+grafana so get on it early. * VPN instead of securing internal services. Attack surface is way too high if you’ve too many services. Just throw them all behind a vpn and expose selectively. I use WireGuard. * personally: don’t self host critical infrastructure. I can’t afford downtime on email etc so I rather just pay someone to host that. Personal infra is for fun, not a second job (and I’m an SRE).

MiscIdeaMaker99 5y ago
> Have mandatory reboots, never be afraid of reboots. Yes! It is not a badge of honor to have a server that's been online for 365+ days -- it just means you haven't applied any kernel security updates for a long, long time. :-p
- toast0 5y ago
  > Yes! It is not a badge of honor to have a server that's been online for 365+ days The badges come at 1000 days and every 500 after that. If you have a minimal kernel, and a limited software set, many kernel security bugs found won't apply to your system and you don't need to reboot for them. Not that you need to be scared of reboots, and you should probably schedule some reboots so you can be confident your systems can reboot, but you also don't need to be scared of uptime or stability, either.
  - addingnumbers 5y ago
    1000 days of uptime is 1000 days of configuration drift since the last time you confirmed your services still boot properly. I don't want to wait for a power failure to find out whether my services still recover from a cold boot.
    - toast0 5y ago
      If your push process is reasonable, you don't need to confirm boot time config changes on all machines. When you make a boot time config change (which, in my mind, includes kernel version and OS version to some extent), decide if it's nice to have or needs to have. If it's needs to have, well everything gets rebooted and no badges for a while. If it's nice to have, group hosts by kernel version and hardware spec and reboot one or two hosts with median uptime; your config will be tested, and you can still earn badges. If you can't tell what configs are boot time or not, just reboot a median uptime host in each group once a week. If you can't tell what's important enough to reboot everything, I guess you can just reboot everything every 49.7 days, but you'll never get badges that way. You also won't get production data comparing current kernel to older kernel to see if any new software would have worked better on older kernels, so you have some data to start with when you hit new bottlenecks.

by isatty 5y ago

MiscIdeaMaker99 5y ago

> Have mandatory reboots, never be afraid of reboots. Yes! It is not a badge of honor to have a server that's been online for 365+ days -- it just means you haven't applied any kernel security updates for a long, long time. :-p

toast0 5y ago
> Yes! It is not a badge of honor to have a server that's been online for 365+ days The badges come at 1000 days and every 500 after that. If you have a minimal kernel, and a limited software set, many kernel security bugs found won't apply to your system and you don't need to reboot for them. Not that you need to be scared of reboots, and you should probably schedule some reboots so you can be confident your systems can reboot, but you also don't need to be scared of uptime or stability, either.
- addingnumbers 5y ago
  1000 days of uptime is 1000 days of configuration drift since the last time you confirmed your services still boot properly. I don't want to wait for a power failure to find out whether my services still recover from a cold boot.
  - toast0 5y ago
    If your push process is reasonable, you don't need to confirm boot time config changes on all machines. When you make a boot time config change (which, in my mind, includes kernel version and OS version to some extent), decide if it's nice to have or needs to have. If it's needs to have, well everything gets rebooted and no badges for a while. If it's nice to have, group hosts by kernel version and hardware spec and reboot one or two hosts with median uptime; your config will be tested, and you can still earn badges. If you can't tell what configs are boot time or not, just reboot a median uptime host in each group once a week. If you can't tell what's important enough to reboot everything, I guess you can just reboot everything every 49.7 days, but you'll never get badges that way. You also won't get production data comparing current kernel to older kernel to see if any new software would have worked better on older kernels, so you have some data to start with when you hit new bottlenecks.