Archive

Archive for the ‘Backup’ Category

Backing up Der Flounder Revisited

February 12, 2021 2 comments

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.

Read more…

Categories: Backup, Linux, Raspberry Pi

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

February 16, 2020 Leave a comment

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.

Read more…

Reclaiming drive space by thinning Apple File System snapshot backups

April 7, 2018 16 comments

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.

Screen Shot 2018 04 07 at 2 04 39 PM

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:

Read more…

Backing up Der Flounder

March 19, 2012 Leave a comment

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.

Read more…

Categories: Backup, Scripting, Technical

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

May 26, 2011 1 comment

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.

Read more…

Uninstalling the Retrospect 6.x backup client

April 1, 2011 3 comments

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?

March 28, 2010 1 comment

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.

%d bloggers like this: