Archy's Blog

Rsync is a very easy way to transfer large amounts of files between servers with low resource usage which also makes for a great backup target due to its speed and flexibility. Here's a small write-up on how to set up a basic rsyncd server: First, install the required packages: [archy@mirror01~]$ sudo yum -y --refresh install rsync rsync-daemon Create the rsync root directory, I'll place all my sub-modules (folders) in '/var/rsync' [archy@mirror01 ~]$ mkdir -p /var/rsync/{rpms,backup} Setting the SELinux boolean and file context: [archy@mirror01 ~]$ sudo semanage boolean -m -1 rsync_full_access [archy@mirror01 ~]$ sudo semanage fcontext -a -t 'public_content_t' '/var/rsync(/.*)?' [archy@mirror01 ~]$ sudo restorecon -Rv /var/rsync Creating /etc/rsyncd.conf: [archy@mirror01 ~]$ sudo vim /etc/rsyncd.conf pid file = /var/run/rsyncd.pid log file = /var/log/rsyncd.log lock file = /var/run/rsyncd.lock address = 0.0.0.0 port = 873 ...

A broken rpmdb can happen when packages are updated outside of rpm / yum being notified and therefore the rpmdb being in an inconsistent state or if the partition where your rpmdb resides runs out of disk space. This is the error I'm getting: error: rpmdb: BDB0113 Thread/process 6245/139652028413760 failed: BDB1507 Thread died in Berkeley DB library error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in /var/lib/rpm CRITICAL:yum.main: Error: rpmdb open failed Fixing it is very simple. First, create a backup of the current rpmdb just in case things go sideways: [root@server ~]# tar -cvpJf /var/tmp/rpmdb_$(date +%F).tar.xz /var/lib/rpm/__db.* Now that you have a backup, remove the rpmdb files: [root@server ~]# rm -f /var/lib/rpm/__db.* With the rpmdb deleted, go ahead and rebuild rpm's db: [root@server ~]# rpm...

Using lvm has multiple advantages especially since hard drives can be added, and pooled. But with hard drives aging, they need to be swapped out in order to guarantee proper availability. Since with lvm, drives become irrelevant, this process is very easy. First, create the physical volume: [root@server ~]# pvcreate /dev/sdc1 Now, extend the volume group: [root@server ~]# vgextend /dev/vg_backup /dev/sdc1 With the volume group extended, the physical extents can be moved: [root@server ~]# pvmove /dev/sdb1 /dev/sdc1 This process can take a while depending on the drive speeds and sizes. Once the physical extents are moved, remove the old drive from the volume group: [root@server ~]# vgreduce /dev/vg_backup /dev/sdb1 The drives are now switched and the old drive can be removed from the system. Feel free to comment and / or suggest a topic.

Fedora 31 has been released at the end of October 2019 so it's time for me to update. Fedora Updates have proven to be reliable but Updates can go wrong and for that case, I want to have a fallback that I can utilize to restore my system without much of a hassle. I use LVM for all my Storage so the solution for me was fairly easy: LVM Snapshots. I'm using one volume group for the system named 'vg_base'. If you are copy-pasting the commands, this is the one parameter you'll have to adjust. Without further ado, let's get through the upgrade scenario. While these commands can be executed as user with sudo privileges, I find it easier to do these as root. Install the system-upgrade plugin [root@castle-bravo ~]# dnf -y install dnf-plugin-system-upgrade Now create the snapshots of all the system lvs. Note that you would only need to snapshot the rpmdb as well as the logical volumes containing /etc/, /bin, /sbin, /usr/bin and /usr/sbin but to be on th...

Making consistent Backups is key to successful disaster recovery. I've found LVM and its snapshot functionality very helpful in that regard. So I'll cover how to create a snapshot and back it up in a consistent state and restore reliably. First things first, you'll need to have some free space in your volume group, I'll be demonstrating this in a virtual machine. First up, let's start by creating a snapshot of a volume: [archy@server ~]$ sudo lvmcreate -s -n lv_home_$(date +%Y%m%d) -L 10G /dev/vg_base/lv_home This will create a snapshot with 10G COW Space which will fill up once you are writing to the lvm you've specified above. In my case, it's the '/home' mount point on the system and I'm assuming that while the backup is running, I won't write 10G of data. Keep in mind that it is possible to create automatic extending snapshots using the lvm.conf but I will not cover that here. With the snapshot created we can now mount it ...

There are various ways to back up files in linux and most of them are possible through already onboard applications like rsync and tar. I will demonstrate how to backup files using both, tar and rsync with remote and local destination. I will also show how to restore files in case you need it. So let's begin with tar. Options and their meanings will be shown below. Create the archive using tar to a local directory: [archy@host ~]$ tar -cvpzf backup-homedir.tar.gz --exclude=backup-homedir.tar.gz ./* options: c - create a new archive v - verbose output p - preserve permissions z - compression with gzip f - the filename for the new archive Extracting the archive using tar from a local directory: [archy@host ~]$ tar -xvpzf backup-homedir.tar.gz -C /path/to/destination options: x - create new archive v - verbose output p - preserve permissions z - uncompress with gzip f - the filename of the archive If you just need to keep directories in sync. For archiving...