• 0 Posts
  • 15 Comments
Joined 1 year ago
cake
Cake day: July 19th, 2023

help-circle




  • Seperate DB container for each service. Three main reasons: 1) if one service requires special configuration that affects the whole DB container, it won’t cross over to the other service which uses that DB container and potentially cause issues, 2) you can keep the version of one of the DB containers back if there is an incompatibility with a newer version of the DB and one of the services that rely on it, 3) you can rollback the dataset for the DB container in the event of a screwup or bad service (e.g. Lemmy) update without affecting other services. In general, I’d recommend only sharing a DB container if you have special DB tuning in place or if the services which use that DB container are interdependent.




  • Buying your own domain often includes DNS hosting but that’s not really the point unless all you’re doing is exclusively running an externally-facing website or e-mail. The main reason for buying a domain online is so everybody else recognises you control that namespace. As a bonus, it means you can get globally-cognised SSL certificates which means you no longer have you manage your own CA and add it’s root to all the devices which wish to access your services securely. It’s also worth noting that you cannot rely on external DNS servers for entries that point to private IPs, because some DNS servers block that.



  • People who do not wish to buy a GTLD can use home.arpa as it is already reserved. If you are at the point of setting up your own DNS but cannot afford $15 a year AND cannot use home.arpa I’d be questioning purchasing decisions. Hell, you can always use sub-domains in home.arpa if you need multiple unique namespaces in a single private network.

    Basically, if you’re a business in a developed country or maybe developing country, you can afford the domain and would probably spend more money on IT hours working around using non-GTLDs than $15 a year.


  • If your domain will NEVER send e-mail out, you only really need and SPF record to tell other servers to drop e-mail FROM your domain. Even that’s somewhat optional. If you ever plan on sending ANY outbound (you should at very least for the occasional ticket) then do DKIM, DMARC and SPF. The more of these you do, the less likely e-mails FROM your domain are to be flagged as spam.


  • Some servers blacklist you no matter what you do because you’re not a big player in the e-mail space… Outlook. Fuck Outlook. M365 doesn’t do that though.

    Also the idea that reverse IPs are needed (in practice) when SPF, DKIM and DMARC are in use is insane. I have literally told you my public key and signed the e-mail. It’s me. You don’t need to check the damn PTR!




    • Personal and business are extremely different. In personal, you backup to defend against your own screwups, ransomware and hardware failure. You are much more likely to predict what is changing most and what is most important so it’s easier to know exactly what needs hourly backups and what needs monthly backups. In business you protect against everything in personal + other people’s screwups and malicious users.
    • If you had to setup backups for business without any further details: 7 daily, 4 weekly, 12 monthly (or as many as you can). You really should discuss this with the affected people though.
    • If you had to setup backups for personal (and not more than a few users): 7 daily, 1 monthly, 1 yearly.
    • Keep as much as you can handle if you already paid for backups (on-site hardware and fixed cost remote backups). No point having several terabytes of free backup space but this will be more wear on the hardware.
    • How much time are you willing to lose? If you lost 1 hour of game saves or the office’s work and therefore 1 hour of labour for you or the whole office would it be OK? The “whole office” part is quite unlikely especially if you set up permissions to reduce the amount of damage people can do. It’s most likely to be 1 file or folder.
    • You generally don’t need to keep hourly snapshots for more than a couple days since if it’s important enough to need the last hours copy, it will probably be noticed within 2 days. Hourly snapshots can also be very expensive.
    • You almost always want daily snapshots for a week. If you can hold them for longer, then do it since they are useful to restoring screwups that went unnoticed for a while and are very useful for auditing. However, keeping a lot of daily snapshots in a high-churn environment gets expensive quickly especially when backing up Windows VMs.
    • Weekly and monthly snapshots largely cover auditing and malicious users where something was deleted or changed and nobody noticed for a long time. Prioritise keeping daily snapshots over weekly snapshots, and weekly snapshots over monthly snapshots.
    • Yearly snapshots are more for archival and restoring that folder which nobody touched forever and was deleted to save space.
    • The numbers above assume a backup system which keeps anything older than 1 month in full and maybe even a week in full (a total duplicate). This is generally done in case of corruption. Keeping daily snapshots for 1 year as increments is very cheap but you risk losing everything due to bitrot. If you are depending on incrementals for long periods of time, you need regular scrubs and redundancy.
    • When referring to snapshots I am referring to snapshots stored on the backup storage, not production. Snapshots on the same storage as your production are only useful for non-hardware issues and some ransomware issues. You snapshots must exist on a seperate server and storage. Your snapshots must also be replicated off-site minus hourly snapshots unless you absolutely cannot afford to lose the last hour (billing/transaction details).