BackupPC - binary garbage in XferLog.z / XferLog.z getting huge
I run a BackupPC instance that is still on Debian 10 / buster. The latest rsync package for Debian 10 has version number 3.1.3-6.
I recently noticed infrequent issues when backing up hosts that are either on Debian 11 / bullseye, or on Ubuntu 22.04 (which both ship rsync 3.2.3). The symptoms are as follows:
- backups take much longer than usual
- XferLog.z starts "normally", but after a certain point contains a lot of binary garbage, and gets much bigger than usual (hundreds of MB, or even in one case up to 12 GB)
After investigating and looking for information online, I came across these bug reports, which contain the explanation as well as a workaround: Debian Bug report #969463 and BackupPC issue #369.
=> The issue is caused by a combination of a change of default behaviour introduced with rsync 3.2.3, and a bug in File::RsyncP.
The solution that works for me (pending an update to Debian 11 and BackupPC 4) is to add the following line in the individual server config for each of the affected hosts:
I recently noticed infrequent issues when backing up hosts that are either on Debian 11 / bullseye, or on Ubuntu 22.04 (which both ship rsync 3.2.3). The symptoms are as follows:
- backups take much longer than usual
- XferLog.z starts "normally", but after a certain point contains a lot of binary garbage, and gets much bigger than usual (hundreds of MB, or even in one case up to 12 GB)
After investigating and looking for information online, I came across these bug reports, which contain the explanation as well as a workaround: Debian Bug report #969463 and BackupPC issue #369.
=> The issue is caused by a combination of a change of default behaviour introduced with rsync 3.2.3, and a bug in File::RsyncP.
The solution that works for me (pending an update to Debian 11 and BackupPC 4) is to add the following line in the individual server config for each of the affected hosts:
$Conf{RsyncArgsExtra} = ['--no-msgs2stderr'];
3D-Fuel Pro PLA+ material profile for Cura LulzBot Edition / LulzBot Mini printer
For some reason, Cura LulzBot Edition does not include a material profile for Pro PLA+ by 3D-Fuel used on a LulzBot Mini printer.
Here are the settings that work for me: 3d-fuel-pro-pla.xml.fdm_material (2.85 mm).
Here are the settings that work for me: 3d-fuel-pro-pla.xml.fdm_material (2.85 mm).
Split a multi-object STL file into separate files containing each one object
slic3r --split input.stlThis will create input.stl_01.stl, input.stl_02.stl etc. in the same directory.
This worked perfectly for me on a file created with OpenSCAD containing different parts that I wanted to print individually with Cura Lulzbot Edition. I found the info here.
Find large files in a BackupPC transfer log (sort files in XferLOG by size)
When your backups suddenly takes much longer to complete, it could be because large files that were previously excluded from the backup were renamed or relocated elsewhere. In order to identify those files, or just to sort the list of files by size, I use the following code (bash):
Note: on Debian, BackupPC_zcat is in /usr/share/backuppc/bin/. I've added a symlink in /usr/local/bin/ so that I don't need to look for it every time.
cd /tmp/This will show the list of files bigger than 99999999 bytes (100 MB). Remove "| egrep '[0-9]{9,}'" to just list all instead.
BackupPC_zcat /var/lib/backuppc/pc/mypc/XferLOG.99.z > xlog
for S in `cat xlog | sed -e 's/^[^/]*\/[0-9]*[ ]*//' | cut -f1 -d\ | egrep '^[0-9]+$' | egrep '[0-9]{9,}' | sort -n | uniq ` ; do fgrep " $S " xlog ; done
Note: on Debian, BackupPC_zcat is in /usr/share/backuppc/bin/. I've added a symlink in /usr/local/bin/ so that I don't need to look for it every time.