This blog is not intended to offer anything extraordinary; instead, consider it an anecdote, a lesson, or simply a proper way of doing things without the need to run a test when in doubt.

That said, I must emphasize that, as always, testing everything before deploying to production is essential.

Let’s dive into the story: while I was working on a specific task, a colleague sent me a message asking the following: 

Hey Fernando!
If an xb is encrypted + compressed, what should be done first? Decompress or decrypt?

Remember, I was focused on something else, but in my eagerness to help him reasonably quickly, without testing and trying to use common sense, I responded as follows:

Good question!
Decrypt, then decompress.

That makes sense, right? He first agreed: it made sense. Then, minutes later, everything changed: it seemed that it wasn’t the case. He replied to me:

I checked with another colleague, and the opposite is true: decompress and decrypt.

I said, “OK, sorry for the inaccurate response,” and moved on, worried.

A few days later, I had to execute a change involving rebuilding a replica using a compressed and encrypted backup (how curious, right? I wonder who wrote it, ha).

Anyway, when the moment of truth came, I saw the steps as suggested by that colleague:

    • Decompress the backup
    • Decrypt the decompressed data

To my surprise, the first operation didn’t do anything at all: it gave only a generic false output like this (ignore the dates and everything else; it’s anecdotal)

Then I realized that I was the right one, ha! It was the opposite.

    • Decrypt the backup
    • Decompress the decrypted data

Here’s why it should be done this way: Compress first. Once encrypted, a file becomes a stream of seemingly data that cannot be compressed effectively. Compression relies on identifying patterns within the data, and encryption removes those patterns, rendering compression futile.

The rest of the steps went smoothly (no need to mention them here).

Anyway, just to prove it’s not just words, here’s the proof.

The backup

The backup files

The restore, starting with decompress first (which, obviously, failed)

Why did it fail? Because the files were the same!

How did it work? Decrypting and then decompressing.

Easter egg: you can do both things at the same time!

Conclusion

Compression is based on recognizing data patterns within files. When you encrypt, you remove those patterns, which makes compressing after encryption practically pointless. Compress first, then encrypt.

Test everything as much as possible. If time constraints prevent this, rely on common sense; above all, testing provides the foundation for everything to proceed smoothly.

With Percona XtraBackup, you can ensure your applications remain fully available and guarantee the consistency and safety of your data files.

Subscribe
Notify of
guest

2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Doug Wiggin

Thanks for the information, Fernando.

0
Reply
Fernando Mattera

My pleasure, Doug.

0
Reply