Backing up Der Flounder Revisited Once Again

Eleven years ago, I wrote a post on how I back up this blog. Overall, the reasons I’m backing up haven’t changed:

• I like this blog and don’t want to see it or its data disappear because of data loss
• WordPress.com’s free hosting doesn’t provide me with an automated backup method.

Two years ago, I wrote another post on how I needed to switch from hosting on a Mac to now hosting on a Raspberry Pi. The overall methodology hadn’t changed, I was creating a nightly mirror using HTTrack. This worked fine until the latest move to a new host in February 2023, where HTTrack was failing for me because the Raspberry Pi was running headless without a connected display and HTTrack was having problems with trying to launch a headless browser. After an hour of futzing with it, I moved to using wget. The wget tool has a number of handy options for mirroring websites, including the following:

• –mirror: Makes the download recursive, with recursive browsing and infinite recursion depth.
• –convert-links: Convert all the links to relative, so it will be suitable for offline viewing.
• –adjust-extension: Adds suitable filename extensions to filenames, (html, css, etc.) depending on their content-type.

Based on my research, using wget would be a decent replacement for what I had been doing with HTTrack and wouldn’t have the problems I was seeing with HTTrack not being able to launch a headless browser session. For those wanting to know more, please see below the jump.

Backing up Der Flounder Revisited

Nine years ago, I wrote a post on how I backup this blog. Overall, the reasons I’m backing up haven’t changed:

• I like this blog and don’t want to see it or its data disappear because of data loss.
• WordPress.com’s free hosting doesn’t provide me with an automated backup method.

To create the backups, I make a nightly mirror using HTTrack. As time has passed and host machines were replaced, I’ve moved the backup host a few times. For the last move, I decided for budgetary reasons to move off of using Macs and onto a Raspberry Pi. For those wanting to know more, please see below the jump.

Backing up a Jamf Pro database hosted in Amazon Web Services’ RDS service to an S3 bucket

For those using Amazon Web Services to host Jamf Pro, one of the issues you may run into is how to get backups of your Jamf Pro database which you can access. AWS’s RDS service makes backups of your database to S3, but you don’t get direct access to the S3 bucket where they’re stored.

In the event that you want a backup that you can access of your RDS-hosted MySQL database, Amazon provides the option for exporting a database snapshot to an S3 bucket in your AWS account. This process will export your data in Apache Parquet format instead of a MySQL database export file.

However, it’s also possible to create and use an EC2 instance to perform the following tasks:

1. Connect to your RDS-hosted MySQL database.
2. Create a backup of your MySQL database using the mysqldump tool.
3. Store the backup in an S3 bucket of your choosing.

For more details, please see below the jump.

Reclaiming drive space by thinning Apple File System snapshot backups

As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.

A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:

tmutil deletelocalsnapshots snapshot-name-here

However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:

Backing up Der Flounder

I’m very fortunate that WordPress.com’s hosting has provided me with a free way to blog without having to worry about anything besides “Is it up?” However, along with the question “Is it up?”, there’s the possibility that the answer someday may be “No”. The usual answer to this problem is “Set up an automated backup”, but I had the following technical issues to deal with:

• Backups can only be made manually via the admin console
• Backups made via the admin console would not include the hosted media (images, videos, etc)
• Media is linked at a separate address
• I do not have shell access to the server(s) hosting the blog (which would allow me to set up a normal WordPress backup)

Fortunately, there’s a relatively straightforward solution: mirror the site to a local backup using HTTrack. See below the jump for the details.

Backing up a Windows 7 Boot Camp installation and restoring it to a smaller partition.

I had set up a Boot Camp installation yesterday for a user, who wanted to use it for both dual-booting and so he could use VMWare (using the Boot Camp partition for the VMWare Windows install.) I’d set it for 100 GBs (20%) of the disk and delivered it, but I got a follow-up email from the user asking if the Windows partition could be made smaller (50 GBs).

Since there’s no easy way I know of to shrink a Windows partition (plenty of options if you want to grow it), I was looking at a multi-hour re-install of Windows 7 which I had just done.

That’s when I remembered my (possible) savior: Winclone . The venerable tool was no longer being updated, but it could still save my bacon. At least, that’s what my hope was.

After some Googling, I happened across this Apple Discussion thread and saw Toocool4‘s post at the bottom of the thread. That was the key information I needed and it helped me immeasurably with avoiding the pain of reinstalling Windows 7 again. See below the jump to get the procedure I used.

Uninstalling the Retrospect 6.x backup client

Something I liked about the old Installer VISE Retrospect backup client installer was that it had an “Uninstall” function. That ability was lost when Retrospect’s builders switched to using standard Apple .pkg installers. There was an unofficial AppleScript uninstaller that was posted in the Retrospect forums, but it didn’t address the issue of 10.6’s receipts being stored in a different directory. So I’ve built this script to take care of uninstalling Retrospect 6.x clients:


#!/bin/sh

sudo killall retroclient
sudo killall pitond
sudo rm -rf /Applications/Retrospect\ Client.app
sudo rm -rf /Library/StartupItems/RetroClient
sudo rm /Library/Preferences/retroclient.state
sudo rm -rf /Library/Receipts/retrospectClient.pkg
sudo rm -rf /Library/Receipts/retroclient.pkg
sudo rm /var/db/receipts/com.retrospect.retroclientstartupitems.pkg.bom
sudo rm /var/db/receipts/com.retrospect.retroclientstartupitems.pkg.plist
sudo rm /var/db/receipts/com.retrospect.retrospectclient.pkg.bom
sudo rm /var/db/receipts/com.retrospect.retrospectclient.pkg.plist


Script available here on my GitHub repository.

It should stop both older and newer Retrospect 6.x clients on both 10.5.x and 10.6.x and clean up all application, settings and receipts files. Because I also wanted to be able to hand this script off as needed to those not necessarily comfortable with running scripts, I’ve also built a script-only installer package to run these commands. It’s posted here for download.

Backups, backups….how do you trust them when you need them?

Since starting my current job around seven years ago, I’ve become a tithing member of the Church of Backups. I helped build backup systems for my office, transitioned from different backup systems to others, and am in the process of transitioning from one system of backing up desktops to another. I also have set up backups for my home and other members of the family. Along the way, I’ve learned a few lessons, so I’ll list them in order of importance to me:

1. Make your backup system as automated as possible – if you’re having to start something manually for your backup to run, you’ll forget to do it on a regular basis. We’re all busy and have a lot of things competing for our attention. Make running your backup be something that’s handled by something that Just Works.

2. Test your backup – if you can’t restore, you don’t have a backup and have spent money, time and energy on something that will be a failure when you need it most. With that in mind, isn’t a little testing worth the time? The only way to find that out how good your backup really is, is to do a restore and see what you have. Testing and finding failures is not a bad thing, it just means you have a chance to fix what’s wrong before you need that backup for real.

3. Check that the backup is actually running properly – Along with the backup that Just Works, have another automated process that’s notifying you regularly that It’s Working. If that’s not possible, add checking your backups to your weekly to-do list.

4. If possible, get a block-level backup solution – At the heart of it, there’s two different kinds of backups. The first is a file-level backup, which tracks and backs up entire files. (On the Mac side, both Retrospect and Time Machine do file-level backups.) The second is a block-level backup, which tracks and backs up files based on how their blocks have changed on the drive level. (on the Mac side, Mozy, CrashPlan and many other Internet backup services work this way.)

Why I prefer a block level solution is that it allows better efficiency in how your backup storage is used and also allows you to back up large files without having to repeatedly recopy the whole large file into your backups. Also, block-level backups are generally better at backing up large files while they’re in use.