• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!
  • 2026 staff recruitment is open! Check it out and consider applying!

Linux The best way to archive, compress and encrypt data in 2026

TibiCAM

Veteran OT User
Joined
Feb 3, 2020
Messages
214
Reaction score
295
There are many ways to archive, compress and encrypt files/folders in 2026. I decided to look into this more closely by reading the manual pages of popular programs like tar, gpg, zstd, lzma, xz, etc. And I also used the GnuPG mailing list, ChatGPT & Claude, and YouTube videos to come up with the best way to compress and encrypt files/folders. I spent a few hours searching for this online but didn't find anyone that combined it all in a single post. And most topics were outdated, which shocked me a bit because this is something every business owner should be doing. If you have anything that needs to be backed up, or files you want to send to someone else, then you must compress and encrypt them properly.

Earlier, I had used 7-Zip with the following command I found here on OTLand:
Bash:
sudo 7z a -t7z -m0=lzma2 -mx=9 -mfb=64 -md=32m -ms=on -mhe=on -p"Tibia123!" "test.7z" "test/"

It did its job quite well. It compressed the files using lzma2, it hid the file names, it set a passphrase ("Tibia123!") and created a file called "test.7z". But it wasn't secure enough for 2026. Brute force attacks have become more sophisticated, and it used an older compression algorithm as well which wasn't great in performance or file size. The encryption implementation in 7-Zip also isn't best.

After a bit of digging, I found out that Meta (Facebook) had developed a new compression algorithm called OpenZL in October 2025, which is the next best compression algorithm. But it's targeted towards AI data centers that have complex data types and very, very large file sizes. So I didn't opt for OpenZL in my case. But for those that are interested in it, see here. It's much faster than zstd and lzma, but it's not meant for smaller archives. This is perfect if you're compressing terabytes of data however.

Website: OpenZL (https://openzl.org/)
Research paper: https://arxiv.org/pdf/2510.03203
YouTube (The Linux Foundation):

But then I listened to what he said in the video, and I started looking more into the other options. And I came to the conclusion that the best way of archiving, compressing and encrypting files and folders is to use a combination of tar, gpg and zstd. Archiving and compression tools are great at their own things, but not encryption - and vice versa. Which is exactly what I did and got great results. Not only is it now extremely fast at compressing files, but it also offers top-notch security and privacy. It ensures file names are hidden and that no excess metadata is included in the archive. This will allow me to safely upload whatever files I have to cloud storage services without risking them inspecting my files.

Start by installing the required packages:
Bash:
sudo apt install -y tar gnupg zstd

Then use the following command to archive, compress and encrypt your files. In this case it takes the folder "source_dir" (where you put your files) and encrypts it using a passphrase (in this case "Tibia123!"). You can of course also pass in a single file (without a folder).

Bash:
tar -cf - \
    --sort=name \
    --format=posix \
    --pax-option="delete=atime,delete=ctime" \
    --numeric-owner \
    --owner=0 \
    --group=0  \
    --no-selinux \
    "source_dir/" |
zstd -10 -T0 --long |
gpg -c \
    -q \
    --batch \
    --no-tty \
    --no-greeting \
    --s2k-cipher-algo AES256 \
    --s2k-digest-algo SHA512 \
    --s2k-count 65011712 \
    --cipher-algo AES256 \
    --digest-algo SHA512 \
    --compress-algo none \
    --pinentry-mode loopback \
    --no-symkey-cache \
    --passphrase "Tibia123!" \
    -o "$(date +%Y-%m-%d)-backup.tar.zst.gpg"

This will generate a file called i.e. "2026-05-29-backup.tar.zst.gpg". That's the file you can share/upload wherever. I will personally use this for daily backups of my databases.

The default settings for all these programs are not sufficient for a secure way of encrypting or backing up data in 2026, which is why we have to explicitly set all those settings. It ensures the encryption is future-proof for at least 20 years (according to security professionals). And as I mentioned, this will also remove excess metadata from the archive so that nobody can even guess what is inside of it without the passphrase. Because when you upload a file to i.e. Dropbox or Google Drive, they will most certainly use OCR and other technologies to scan through your files. It's even part of their privacy policies. So by encrypting the files before uploading them anywhere, you ensure your data stays private. And you want to ensure you're using the latest technology, because if you use tools from 2010, they are already outdated by today's standards.

The only way to access the data is by decrypting the files using the passphrase you set. To make it slightly more secure, you could use a passphrase file. That way there is no command history on your server, in case your server gets compromised. But to make it convenient, this will do for most use cases. You can also omit the "--passphrase" parameter and use the interactive mode instead. That way it will ask you to submit the passphrase, and there are no terminal logs of it. But in my case I want to be able to automate this using a cronjob on my server, by providing the passphrase each time.

You can then delete the unencrypted folder:
Bash:
sudo rm -rf "source_dir/"

To decrypt the encrypted archive, you run the following and provide the passphrase:
Bash:
gpg -q -d 2026-05-29-backup.tar.zst.gpg | zstd -d | tar -xf -

You can also run the following to inspect the content of the archive (without extracting any files):
Bash:
gpg -d 2026-05-29-backup.tar.zst.gpg | zstd -d | tar -tvf -

And if you're interested in inspecting the encrypted file to ensure it's secure, you can see some examples below. It should specify that it is a file type of "PGP symmetric key encrypted data - AES with 256-bit key salted & iterated - SHA512" and the last two commands should fail, because it hasn't been decrypted.
Bash:
# Inspect the file type
file 2026-05-29-backup.tar.zst.gpg

# Attempt to peek inside without decrypting (should fail):
tar -tvf 2026-05-29-backup.tar.zst.gpg

# Try to zstd directly (should fail):
zstd -d -c 2026-05-29-backup.tar.zst.gpg | tar -xvf -

This resulted in better performance + file size + security + privacy than using 7-Zip as I had used earlier. So just create a folder e.g. "source_dir" and put all the files you want to encrypt inside there. You can also run it on a single file (without creating a folder). Then run the commands above, and take the encrypted file and upload/send it wherever you need. Lzma4 can provide better compression in some cases (=smaller file size). But the speed is much, much slower than zstd3. And zstd is the recommended compression algorithm for most file types, especially text files.

The above method can be used for anything. It can be used for daily backups (like in my case), or whenever you upload/transfer files to other people or services. If you're sending anything that contains any form of sensitive data, or data you don't want to share with anyone, then you should most definitely use this. Not only do you get much smaller file sizes, but you also ensure your files are encrypted.

Just make sure that you protect it using a secure passphrase. Use the following page to learn what a good passphrase looks like: Diceware Passphrase Home (https://theworld.com/~reinhold/diceware.html). And you should of course store it in a password manager such as KeePassXC or something else.

Manuals:
 
Last edited:
Very good write up! Works perfectly!
Do you think it could be worth using openzl also for smaller files instead of zstandard?
 
Very good write up! Works perfectly!
Do you think it could be worth using openzl also for smaller files instead of zstandard?

I haven't tried it myself. But I'd also guess using OpenZL can have some issues on some hardware. It's very new and I don't think there's hardware acceleration available yet. I think it's best to use zstd for a while longer before moving to OpenZL.
 
Back
Top