Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: zstd compression #95

Open
arthurfreycobraag opened this issue Sep 6, 2019 · 4 comments
Open

Feature request: zstd compression #95

arthurfreycobraag opened this issue Sep 6, 2019 · 4 comments

Comments

@arthurfreycobraag
Copy link

arthurfreycobraag commented Sep 6, 2019

Would it be possible to add the zstd compression method? I'm using it with xcp-ng 8 and have found that the backups are smaller and quicker compared to gzip or similar compression methods.

See: https://xcp-ng.org/blog/2018/12/19/zstd-compression-for-xcp-ng/
Or: xcp-ng/xcp#66

@NAUbackup
Copy link
Owner

The only issue there is that it's not compatible with the standard Citrix distribution and would require a separate utility to be made available. I can try to look into how much of a maintenance overhead this might be.
I do agree that gzip is not a great utility: zstd, pigz and LZ4 are all better!

@BogdanRudas
Copy link

XCP-ng doing the compression within dom0 with zstd, so once you are exporting from XCP-ng you can enable compression and there will be zstd. It was made to decrease network traffic between XOA and XCP-ng hosts. Surely it is possible to export uncompressed data (which is default) and apply any compressor within backup scripts, but if you need capable networking for this or run scripts in dom0 (which is prohibited by Citrix). And once you have capable networking you can have NTFS compressions for Windows-based file servers and lz4 on ZFS or offline de-duplication for XFS.

@NAUbackup
Copy link
Owner

We do the backup uncompressed (since gzip is so inefficient) and let the host on which the NFS mount resides do all the compression work, which takes a lot of the CPU load off XS/CH. The traffic and backup time will in some cases smaller with in-line compression. It's best to test both to see what works out better in your individual environment.

@arthurfreycobraag
Copy link
Author

In our case, zstd compression was the best thing that could happen. The CPUs are always around 5-20%, so no real strain on them. With gzip we completed backups in a timeframe of around 8h. zstd is now almost half that time, 4.5h While pigz was a compromise of around 6h.

As @BogdanRudas said, you'll need capable network to run full backups quickly. But we can only use 2x1Gbps for now. So zstd it is.

One possibility would be to just parse the text to vm-export. Then have a line in the help that says "zstd compression is only supported on xcp-ng >7.6"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants