Use synching on several devices to replicate data I want to keep backups of. Family photos, journals, important docs, etc. Works perfect and I run a relay node to give back to the community given I am on a unlimited data connection.
At the core it has always been rsync and Cron. Sure I add a NAS and things like rclone+cryptomator to have extra copies of synchronized data (mostly documents and media files) spread around, but it’s always rsync+Cron at the core.
I use Restic, called from cron, with a password file containing a long randomly generated key.
I back up with Restic to a repository on a different local hard drive (not part of my main RAID array), with --exclude-caches as well as excluding lots of files that can easily be re-generated / re-installed/ re-downloaded (so my backups are focused on important data). I make sure to include all important data including /etc (and also backup the output of dpkg --get-selections as part of my backup). I auto-prune my repository to apply a policy on how far back I keep (de-duplicated) Restic snapshots.
Once the backup completes, my script runs du -s on the backup and emails me if it is unexpectedly too big (e.g. I forgot to exclude some new massive file), otherwise it uses rclone sync to sync the archive from the local disk to Backblaze B2.
I backup my password for B2 (in an encrypted password database) separately, along with the Restic decryption key. Restore procedure is: if the local hard drive is intact, restore with Restic from the last good snapshot on the local repository. If it is also destroyed, rclone sync the archive from Backblaze B2 to local, and then restore from that with Restic.
Postgres databases I do something different (they aren’t included in my Restic backups, except for config files): I back them up with pgbackrest to Backblaze B2, with archive_mode on and an archive_command to archive WALs to Backblaze. This allows me to do PITR recovery (back to a point in accordance with my pgbackrest retention policy).
For Docker containers, I create them with docker-compose, and keep the docker-compose.yml so I can easily re-create them. I avoid keeping state in volumes, and instead use volume mounts to a location on the host, and back up the contents for important state (or use PostgreSQL for state instead where the service supports it).
It really depends. I work for a large company and we use Ubuntu, Oracle, RedHat, and SLES. We were moving from Oracle to Ubuntu but now we are going back to RedHat.
Currently we deploy like this: Ubuntu: PostgreSQL, web servers, some engineering workstations, and big data Oracle & RedHat: web servers, security applications, and network systems
So just having a fundamental understanding of Linux and you will be fine SUSE: SAP and HR software
Mostly cost. We used to run a lot of Oracle databases and they have become extremely expensive to keep running. So we are migrating to PostgreSQL. The servers were getting migrated to CentOS but now that RedHat fucked that distro we are going back to RedHat. Part of that deal is switching from chef to Ansible. So to save costs we are consolidating to a single vendor.
Oracle DB are sucking a lot of money, but they fork RHEL for free…(well it is open for everyone), they offer more expensive contract on top of Oracle DB, what a free estate… haha… Nice work ORACLE… :/
Red hat with UBI-Micro still mostly deployed after alpine in enterprise and mission critical server, so let us see if it’ dwindling in next 3-5 years ahead.
For production server? No. mostly NixOS is for desktop.
Ansible cover what nixOS doesn’t in Debian/RHEL space, and it’s idempotent and better than nixOS config. Unless they change their approach for server, I don’t see any way in near future it will be massively adopted.
I’ve been installing Gentoo on my every machine. But I realistically could install Alpine on those few that I don’t use so often. At least I’m gonna test. It’s been years since I used Alpine on any machine.
I rotate between a few computers. Everything is synced between them with syncthing and they all have automatic btrfs snapshots. So I have several physical points to roll back from.
For a worst case scenario everything is also synced offsite weekly to a pCloud share. I have a little script that mounts it with pcloudfs, encfs and then rsyncs any updates.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.