You can actually already control what to backup by fine tuning the task parameters. For example:
This list does not include domains data and email data. You can see what options available by triggering custom ad-hoc backups from the GUI and checking what task command gets written into /usr/local/directadmin/data/task.queue.
This can get close, but not exact.
Using -
action=backup&database_data_aware=yes&domains=all&email_data_aware=yes&select0=autoresponder&select1=database&select10=subdomain&select11=trash&select12=vacation&select2=database_data&select3=dns&select4=email&select5=emailsettings&select6=forwarder&select7=ftp&select8=ftpsettings&select9=list&start=1658513913&trash_aware=yes&type=sitebackup&value=%user%
That is unselecting
Domains Directory: Backs up all user files for all domains and E
-mail Data: Includes the messages from the Inbox, IMAP Folders, and webmail data.
Gets close - but the backup package is missing:
backup/%domain%/email/data/
backup/email_data/
backup/email_data/webmail/
backup/%domain%/email/last_login/
directories. This is all I've found missing in limited tests.
The only way to get that information is to select E-mail Data: Includes the messages from the Inbox, IMAP Folders, and webmail data - and then you get the full
imap/%domain%/%emaillocalpart%/Maildir/
for each email account.
Or maybe there is another, better way to accomplish what I'm after.
I'm wanting a backup package of all of the files, configs, other files that is necessary to recreate the account from backup. So that I can create this tar file, restore it on another server, and then the account is setup exactly like it was on the original server. I don't need anything in the account's home directory for this - other than what might be necessary to restore the account (?? Not sure if there is anything in the home directory, I wouldn't think so). The account's home directory is rsynced separately, so that after I restore the tar package, I can just move the rsync'd home directory into place on the server (and change some ownerships) and then the account is just like it was on the original server.
Reason being - if an account is huge - say 50GB - it's a waste of process time taring up the account's full home directory every single night that the backup is run, when only a few kilobytes is changing in the account's home directory. And the home directory is going to be the bulk of disk space that an account consumes.
It makes more sense to use processing time to just create a small .tar file that contains all the necessary information to "recreate" the account on another server. And then keep an rsync'd copy of the account's home directory saved separately, since rsync can just process the changed data in the account's home directory.
The .tar file will probably have to contain the account's database dumps and those would have to be restored by the restoration process when the account is "recreated" and there's a decent chance that some of those database dumps might be significantly large. But right now that's not really a concern. There's no way to really incrementally backup the database dumps anyway (the dumps still have to be created from scratch in order to compare differences - and at that point you might as well just copy a backup of the data dump).
This is a process I've used on the other control panel for years and it's worked quite nicely. We have some accounts that are 300GB in size and it usually takes less than a minute to create the backup .tar file, send that to a backup server, and rsync the minute differences in the account's home directory to a backup server. Backing up the full home directory or even just the mail in every backup run would take hours.
.
