I had been using the old cpanel_to_da.sh script that I believe was in CustomBuild. It looks like this has since changed to /usr/local/directadmin/shared/cpanel_to_da/cpanel_to_da.sh
Not a huge issue with this. I do note that /usr/local/directadmin/shared/cpanel_to_da/cpanel_to_da.sh is compressing the output package with zstd without regard to the the zstd setting in /usr/local/directadmin/conf/directadmin.conf. This isn't a huge deal except that restoring this package doesn't seem to understand the compression being used.
/usr/local/directadmin/directadmin taskq --run="action=restore&ip_choice=select&ip=%IP%&local_path=/home/admin/admin_backups&owner=admin&select0=user.admin.%username%.tar.zst&type=admin&value=multiple&when=now&where=local"
Comes back with tar expecting to see a tar file, but since the tarball is compressed with zstd - it's not knowing it need to uncompress the tarball first.
This can be remedied by uncompressing the zstd tarball before running the restore task
unzstd /home/admin/admin_backups/user.admin.%username%.tar.zst
But just seems to be an unnecessary extra step.
Would being able to pass an overwriting zstd variable as an environment variable to to the restore task be a solution?
zstd=1 /usr/local/directadmin/directadmin taskq --run="action=restore&ip_choice=select&ip=%IP%&local_path=/home/admin/admin_backups&owner=admin&select0=user.admin.%username%.tar.zst&type=admin&value=multiple&when=now&where=local"
In the interim I'll just add the unzstd command before the restore task so that the restore task works, and I suppose that's an OK workaround. I just thought there might be a better solution.
Reason I'm not using compression is to value speed over disk space savings. Any compression you use is going to take longer to package and unpackage at both ends. It may just be a fraction of a second for some things. But for me, from an efficiency standpoint, I prefer speed over disk savings.
Not a huge issue with this. I do note that /usr/local/directadmin/shared/cpanel_to_da/cpanel_to_da.sh is compressing the output package with zstd without regard to the the zstd setting in /usr/local/directadmin/conf/directadmin.conf. This isn't a huge deal except that restoring this package doesn't seem to understand the compression being used.
/usr/local/directadmin/directadmin taskq --run="action=restore&ip_choice=select&ip=%IP%&local_path=/home/admin/admin_backups&owner=admin&select0=user.admin.%username%.tar.zst&type=admin&value=multiple&when=now&where=local"
Comes back with tar expecting to see a tar file, but since the tarball is compressed with zstd - it's not knowing it need to uncompress the tarball first.
This can be remedied by uncompressing the zstd tarball before running the restore task
unzstd /home/admin/admin_backups/user.admin.%username%.tar.zst
But just seems to be an unnecessary extra step.
Would being able to pass an overwriting zstd variable as an environment variable to to the restore task be a solution?
zstd=1 /usr/local/directadmin/directadmin taskq --run="action=restore&ip_choice=select&ip=%IP%&local_path=/home/admin/admin_backups&owner=admin&select0=user.admin.%username%.tar.zst&type=admin&value=multiple&when=now&where=local"
In the interim I'll just add the unzstd command before the restore task so that the restore task works, and I suppose that's an OK workaround. I just thought there might be a better solution.
Reason I'm not using compression is to value speed over disk space savings. Any compression you use is going to take longer to package and unpackage at both ends. It may just be a fraction of a second for some things. But for me, from an efficiency standpoint, I prefer speed over disk savings.