Cron Job to Create Backups for User Level

I'm wondering if DA will come with feature to auto create backups for User Level using Cron Scheduler.

Basically, I under that DA Admin/Reseller Level has the capability to schedule backups of databases, emails, files & etc. using Cron via DA. However, the filename created is less than ideal. Imagine the filename "admin.<admin_name>.<user_name>.tar.gz". It basically gives away the login user name (admin_name) of DA to users/customers.

The inability to have date/time info on the created backup filename is also not ideal. This does not allow easier identification of the specific archive during emergency times.

Or do I have to end up writing my own php/shell script to backup the necessary data files and put into the respective user accounts "backups" folder? If so, how can I easily achieve the same level of details in backing up what DA is backing up (i.e. databases, emails, websites, and what others?)?

Thanks for the kind hearted

Cheers,
Steven

stevenkly said:

I'm wondering if DA will come with feature to auto create backups for User Level using Cron Scheduler.

Click to expand...

Not a bad idea. Have you considered making it a request?

Basically, I under that DA Admin/Reseller Level has the capability to schedule backups of databases, emails, files & etc. using Cron via DA. However, the filename created is less than ideal. Imagine the filename "admin.<admin_name>.<user_name>.tar.gz". It basically gives away the login user name (admin_name) of DA to users/customers.

The inability to have date/time info on the created backup filename is also not ideal. This does not allow easier identification of the specific archive during emergency times.

Click to expand...

I'm not sure what you're referring to; I just created a user backup for one of my domains, from a user-level login:

Or do I have to end up writing my own php/shell script to backup the necessary data files and put into the respective user accounts "backups" folder? If so, how can I easily achieve the same level of details in backing up what DA is backing up (i.e. databases, emails, websites, and what others?)?

Click to expand...

Feel free to write whatever you need. One of the beauties of DirectAdmin is that users can add functionality, whether through plugins or standalone programs.

If you untar one of the DA backups you'll see what you need to backup in your own scripts. But feel free to make any changes you need.

Jeff

I personally just hacked the sysbk script to take an option that does a full daily backup of the following:

1. Backup of all of /etc
2. Backup of all mail (/var/spool/mail and virtual domains)
3. Full backup of /usr/local
4. Full backup of /home
5. Full backup of /var/log
6. Full database dump

I then rotate the backups every 31 days.
I also retain the 1st monthly.

Works for me.

Hi,

jlasman, i understand that we can create a user backup tar.gz file using the panel and it will create e.g. backup-Aug-20-2007-1.tar.gz. However, it's manual process. I'm looking at the function where user can schedule this process using cron.

mattb, yes, yr script is good for backups kept by admin. But, backups that are meant for customers (user-level) should be splitted according to their user account.

I'm surprise that no other admin/resellers need this feature. I understand that admin/reseller can create a schedule backup for users but the created backup filename is makeup of the admin/reseller login account name e.g. "admin.<admin_name>.<user_name>.tar.gz". I thought it's not good enough. Create another cron job to rename the filenames seems troublesome and not practical.

Cheers.

I just run the backup crons on reseller level and system level.
So no need for a user to make a backup.
(they are safe + don't loose storage space = userfriendly )

If it was done on userlevel they might get into trouble with their storage-max.

You could make an sh script that would copy the users backup to their directory and chown it to their username.

But DA counts all files from owner and adds it to their used space.

Unless you make the script a bit more friendly:
- user can turn it on in their usercp.
- user can say how many days to save it.

(or chown it as for example backupuser on backup, and when user wants to restore it will chown to username)

stevenkly,

I'm not sure if DirectAdmin has published the commands necesary to run a backup, and if so, if they can be run from a user cronjob. Perhaps we should hope for a reply from DA staff.

Jeff

The absolute easiest way to create a cron backup for an end user is to create a root cronjob that runs: as often as you want it to be backed up, where username is the name of the user. It creates the backup in /home/username/backups with the normal dated format.

You just have to be careful, because it will keep adding more backups as time goes on... so deleting old ones would be required if users aren't going to delete them.

One thing to point out is how the Reseller backups are stored. If you take a look at the permissions on the /home/admin/user_backups directory, and the ownership/permissions of the files stored within them, you'll notice that the end user can in fact grab those if he wants to (and knows how).
If you want to give a user access to his file in there, run: which would simply create a symbolic link for them. The only catch with that is that only the user himself can have access to it... apache can't read it, the process doesn't have permission. The DirectAdmin filemanager can't.. it's chrooted... as is any ftp account (chrooted).. so a cgi-bin script would work, or just ssh access would work. I've just mentioned this, as it is that way for a reason. Note users cannot get other user's files in the user_backups directory as they're 640, with the group set to their own group.

As for the date of the backups, that's available on the file's datestamp... which is preserved through wget or ftp transfers (usually), and when using the -p flag with the cp command.

For the question of "will we ever give an end user cron backup options?" .. that's hard to say.. At the moment, no due to the reasons above (Duboux). That could change in the future, but not at the moment.

John