In a previous post, I created a Barman backup script to back up PostgreSQL running in an VM to AWS S3. If you host your PostgreSQL server in Azure, this can get expensive quickly because you pay egress bandwidth fees to Microsoft. In this article, i’ll show you how to use Azure Blob storage instead.

Step 1: Install Barman, barman-cli-cloud, snappy etc.

see original article.

Step 2: Install Azure CLI instead of AWS S3 CLI

Follow the instructions on the Microsoft website.

In my previous post, I showed how to automate backups of a PostgreSQL database to S3 using Barman and barman-cloud-backup.

Step 1: verify hardware architecture and PostgreSQL version

For a successful restore, Barman requires that the hardware architecture and PostgreSQL version are both identical. You can verify these with some simple terminal commands:

rob@pg:~$ uname -m # report architecture
x86_64
rob@pg:~$ psql --version # PostgreSQL version
psql (PostgreSQL) 15.5 (Ubuntu 15.5-1.pgdg22.04+1)

Run these on both the source and target. Obviously, if you dont have the source any more (which is why you’re restoring), you’ll need to make some assumptions…

I was surprised not to find many up to date instructions on this. I have a few basic requirements:

• Back up daily to an S3 bucket
• Keep a certain number of backups
• Run automatically, preferably using systemd not cron as it’s easier to set up and troubleshoot
• Use a user with least privileges on the database, operating system, and in AWS/S3
• Send the results of each backup activity to healthchecks.io

After a bit of playing around, I decided to use Barman for the backups - it’s significantly easier to configure and use than pgBackRest and has native support for backing up to S3, point-in-time restore, and more. The major downside compared to, say, running pg_dump every night, is that it requires an identical setup to restore to - identical hardware and PostgreSQL version. Least privileges in the database is tricky - to be able to back up things like roles, the account basically needs full access to all schemas. The Barman documentation says that it should run as the same user as PostgresQL, postgres.

I’ve been using timescale.com for about a year, but it’s quite expensive for a hobbyist (their cheapest plan in the UK is about $50/month), so I thought i’d try and implement something cheaper. I know i won’t get the cool automatic DR failover or the sexy continuous backups - but it’s not really mission critical if i lose a small amount of the history of my home energy consumption. Timescale publish some instructions, but they weren’t complete, and didnt work for me.

The Aggregation of Marginal Gains is an improvement model attributed to Dave Brailsford. When he took over as the head of British Cycling in 2002, the team was near the bottom of the rankings. Brailsford’s approach was to look at their processes in tiny detail, and improve each part by 1%, the logic being that these would all add up to a significant improvement. He talks about shipping mattresses between hotels so that athletes get a better nights’ sleep, or fastidiously cleaning the team truck to prevent dust and debris undermining the fine tuning of the bikes. And it was a success - in the 2008 and 2012 olympics, the team won 70% of the gold medals for track cycling.

When running apt-get update i was seeing these errors:

W: http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/postgres.gpg are ignored as the file is not readable by user '_apt' executing apt-key.

I was getting this error after migrating keys from the old, legacy store to a the shiny new one.

While running apt-get update I was seeing errors:

W: https://packagecloud.io/timescale/timescaledb/ubuntu/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Although the warning is annoying, it doesn’t stop things updating. I understand the reasons why the legacy keyring is being removed.

I love using devcontainers to manage my development environment. They make it super easy to ensure a consistent development stack is in place. Recently i started developing against a MongoDB instance. For node.js, i use mongodb-unit to spin up a standalone server on the local client. But there’s no equivalent package for Python.

Although there are lots of posts on stackoverflow about configuring a single node replicaset using a healthcheck, and there’s even an example given by a MongoDB employee, they didnt work for me. When setting up the server to use authentication, it also needs a keyfile, which has to be generated and secured in a specific way or you get this error:

I’ve previously explained the RICE and ICE techniques for prioritisation. Both techniques are frameworks used to evaluate and rank projects or tasks based on their potential impact, feasibility, and difficulty. However, I wanted to highlight the two key differences between them to help you chose the right tool for your project.

The ICE technique (Impact, Confidence, Ease) assigns scores to each project based on the potential impact of the project, the level of confidence in its success, and the ease of implementing it. The scores for each factor are multiplied to get a final score, which is used to rank the projects in order of priority.

Yesterday, i talked about the RICE technique for prioritisation. Today, i want to introduce ICE technique, another prioritisation framework used to evaluate and prioritise tasks or projects based on three factors: Impact, Confidence, and Ease. Tomorrow, i’ll compare them both.

• Impact refers to the potential positive outcome or benefit of completing a particular task or project, considering the potential impact of the task or project on the overall goals or objectives of the organisation or project. For example, is this going to reduce costs? Increase customer loyalty or satisfaction? Reduce developer frustration?
• Confidence refers to the level of certainty or confidence that the task or project will be successful - factors such as available resources, expertise, and potential roadblocks or obstacles. Are we likely to be able to deliver?
• Ease refers to the level of difficulty or complexity of completing the task or project, taking account of things like the level of effort required, the time needed, the necessary skills needed, or difficulty obtaining or using resources. Perhaps the project isn’t that hard - but we simply don’t have a developer with the right skills to implement it, or perhaps we can’t support it/keep it running over time.

To use the ICE technique, each item is assigned a score out of 10 for each factor, and the scores are then multiplied together to calculate a final score for each task or project. The higher the final score, the higher we should prioritise completing that item.

Imagine that you are a product manager at a software company, and you have three potential features to prioritise for the next development cycle. How do you pick between them? There are many ways, but one i recently learned about is the RICE model - a prioritisation framework used by product managers, teams, and organisations to prioritise projects, features, or tasks based on their potential impact, effort, and other factors. RICE stands for Reach, Impact, Confidence, and Effort, and it provides a quantitative approach to decision-making.