January 13 2026 U3A IGO, walrus operator, data backup, Pypi wheels

Darren mentioned that he had joined the U3A Linux Discussion Group. Bernie explained that there are lots of Interest Groups Online including astronomy and Pilates which he and Anita respectively attend. They use Zoom.

Steve and Brian initiated a discussion on the use of profiles in Brave and private browsing in Firefox to isolate websites.

Steve commented that he had deactivated tailscale because of the risk that people can get in whereas Brian uses it all the time to maintain contact with home in England. If he detects a problem, he can get a friend to go round to check.

Brian added that he had had to adjust the highly accurate smart thermometer on the heating system because it was going on and off with a 0.2° change so that the heating system was hunting. A boiler should only go on and off three times an hour. Intelligent thermostats work out when to turn off the heating system to avoid overshoot.

John noted that BCB had moved to Bradford Arts Centre in early December 2025. John would be meeting Jonathan before the next meeting.

John went on to say that he had watched Python: The documentary but hadn’t understood what the argument was in 2018 which had caused Guido to step down.

Bernie said that the argument had been over the addition of the walrus operator := . Whereas x==5 validates a statement, x:-5 also makes x equal to the value; it saves an extra step.

Brian reported that he had set up an ESP32 with a digital 3W amplifier and a digital microphone all of which was supposed to work with Home Assistant voice; though he had done the installation via ESPHome and it comes up on Home Assistant, it didn’t come up with a response.

Steve gave a presentation on Data backup with Linux.

His data storage is an openmediavault NAS using ZFS Raid-1 with 3x 6TB HDD.

The backups need to protect against:

• NAS hardware failure — primarily disk failure
• Fire/Water/Building collapse etc.
• Theft or loss!

He noted that there is only one parity disk with ZFS Raid-1 and so he can stand one disk failing but not two. There is a backup mantra: ‘Two is one, one is none.’

His strategy is automated daily backups using a Raspberry Pi 4 attached to an 8TB USB 3.0 HDD which is separated in the house from the NAS by double skinned walls.

He originally used the Raspberry Pi OS but that cannot be updated as easily as Ubuntu. So he now uses an Ubuntu server running a shell script via a cron job. The shell script is loosely based on rsnapshot.

The backup script core concept is:

• Create a copy of the latest snapshot using cp -al; this creates hard-links rather than file copies;
• Update the new snapshot using rsync -a --delete; this will backup any modified/new files from the NAS
• Rename the snapshots to create monthly/weekly/daily backups.

Having monthly backups solves the problem of data being corrupted without you knowing it.

The script is written in BASH; it relies on having rsync, msmtp and hdparm installed.

The backup job pre-checks in the script include:

• check that the script is running as root;
• check that a valid parameter has been passed (daily/weekly/monthly report);
• mount the backup drive on the Pi;
• check that the backup directory is correctly mounted (using a marker file).

The backup is spun down and disconnected between backups.

These checks were added after he discovered that rsnapshot was failing in various situations.

For weekly and monthly backups, the script creates a marker file for the daily backup to process.

For daily backups, the script:

• runs the monthly backup if required;
• runs the weekly backup if required;
• creates a hidden timestamp file in the root of each source directory;
• runs the daily backup;
• deletes the hidden timestamp file in the source directory;
• emails a report ($0 report);
• unmounts the backup drive;
• spins down the HDD (hdparm -y)

Monthly backups take place on the first day of the month and weekly on Saturday, followed by the daily backup (so they can all happen on the same day).

At the report stage the script

• checks that the timestamp files in each backup directory match the current date;
• runs the smartctl test and reports the SMART status of the backup HDD;
• shows the disk usage for the four most recent snapshots of each type in an HTML table.

The configuration for the script is stored in a separate ‘shell script’ which is sourced by the backup script at startup. The log is output to a file on the backup server via ‘LOG’ and ‘DBG’ functions.

(David complimented Steve on the coding standard of the scripts but his countenance changed suddenly when to encountered a double bracket.)

Steve had used a single crontab for all the crontab settings.

The security considerations which Steve had had in mind included:

• no backup encryption because encryption would increase the risk of not being able to restore a backup through loss of keys;
• having good physical control of the backups;
• encrypting anything critical on the NAS;
• not allowing the backup server to mount NAS CIFS/NEFS shares;
• doing remote NAS access via ssh and rsync which is robust and doesn't require any Samba credentials to be stored on the backup server — it only needs the SSH key to work.

Among ideas for improvement/concerns which Steve mentioned were:

• using messages via ntfy in the event of a backup failure;
• using the ZFS snapshot to ensure data consistency;
• improving backup data integrity (data is currently backed up to an ext4 filesystem);
• using ZFS to send/receive snapshots.

He noted that ZFS is both a volume manager and a filesystem — each block is checked. You can put an SSD in front which it uses as a cache before writing to the hard drive. When reading it will read the checksum and, if it is not right, will read the other source.

He added that he had had a disk failure with ZFS in spite of the SMART checks. A problem with ZFS Raid-1 is that, if one disk fails, you are OK but, if two fail, you have a problem.

David noted that there is still a problem with the licensing of ZFS.

Steve uses openmediavault on an HP Microserver; he may switch to FreeNAS as he has got a new NAS limited to 16Gb; he has put the Proxmox server on this along with openmediavault so that it is easy to migrate.

Bernie shared what he had learned since uploading a program to Pypi.

Anyone can use pip install to install packages and this creates no problem for Python programs; however there can be problems with programs that have C components. C is faster as it is not interpreted and there already are C programs for many functions. There is a Python to C layer, for example, for binding to GUI programs.

So Pypi also has wheels which contain compiled binaries for the C components of the program.

pip install looks on your operating system and, if it doesn‘t find the required component, it downloads the source and compiles it for your architecture as long as you have a compiler on your machine. The piwheels website has copy of each wheel and creates wheels for Raspberry Pis.

David pointed out that there will always be a problem if people don’t make programs available for all architectures, for example, by using the Open Build Service. If not, you need to install dependencies.

Past Meetings