reseller backups...

[nobaloney]

I know I'm doing something wrong because I know others have used reseller-level backups to go between systems.

I'm beginning to wish I wasn't .

I've been restoring the reseller this way:

first I create the reseller, using a reseller package already on the server. That works, but the reseller's packages for users don't get restored.

When I restore users some of them get restored and some don't, with errors similar to these:

Cannot restore the pop e-mail account for enquire. You have reached your limit (4).
Cannot restore the pop e-mail account for nancy. You have reached your limit (4).
Cannot restore the pop e-mail account for paul. You have reached your limit (4).

Can someone help me figure this out?

Thanks!

Jeff

 

[matrixx]

Jeff I was just about to post this too...

I suspect that when DA restores a user from a reseller backup there may have been users that have more email addresses set up than their package allowed (maybe the package was downgraded after the user was setup)

I haven't tried to see if Databases or any other features (forwarders or sub doms etc) do the same.

It seems that DA checks the user against package features on restore - I don't think that it is a good idea for DA to check this. Any overages would get flagged in the normal way AFTER restore if it didn't.

Theres a couple of ways around the problem - first is obviously to create the packages as unlimited in the reseller account that is being restored and then adjust them afterwards - thats possible but long winded.

But I'm wondering if it's better for DA to manage package downgrades and 'over allocations' differently by renaming 'over allocated packages' to custom if a package is over allocated after the package profile has been reduced or..

to simply not check for over allocations and allow a straight restore but some how flag the over allocation to the reseller and admin.

I've never had to create the hosting packages before when transferring but now it seems we have to?

Rob

 

[DirectAdmin Support]

You've pretty much summed it up, Rob.

Packages are not required for restores. They aren't checked either, if they do exist.

The reason for the checking is because a user can already exist, and already have a domain with email accounts on it before a restore. In the case of pop accounts, the restore would just add any extra email accounts in the back to the currently active list, without destroying whats already there. So what happens is the list can potentially get larger than it was, hence the check. (existing duplicates and backups are only counted once).

As Rob mentioned, if you lower the pop limit, DA will not delete any pop accounts, so likely the backup was created in the "unbalanced" state, where the limit in the user.conf is less than the number of actual pop accounts.

To resolve, you'd either need to fix it at the source and recreate the backups, or edit backup/user.conf in the user.tar.gz, and change the pop limit, then recompress, then restore.

Another option (if the account is already created) is to but the user.tar.gz into the newly created users backups directory (/home/user/backups). Set the users pop limit higher for the User the usual way. Since the user.conf is not restored when the user restores himself (User Level -> Site Backup), the small backedup limit will not be used, so the pop accounts will restore correctly, going with the actual user limit.

John

 

[matrixx]

To resolve, you'd either need to fix it at the source and recreate the backups, or edit backup/user.conf in the user.tar.gz, and change the pop limit, then recompress, then restore.

Another option (if the account is already created) is to but the user.tar.gz into the newly created users backups directory (/home/user/backups). Set the users pop limit higher for the User the usual way. Since the user.conf is not restored when the user restores himself (User Level -> Site Backup), the small backedup limit will not be used, so the pop accounts will restore correctly, going with the actual user limit.

John

John both options add quite a bit of work especially if you're moving a server with 400 users!

I was wondering if it would be better for DA to automatically rename any current users packages to 'custom' if when the package is downgraded, current users have already used up to their 'higher' limit ?

Rob

 

[nobaloney]

My suggestion (I talked this out with my partner today) is that the limits simply be ignored when restoring.

I see this as the best solution because a backup needs to simply backup the user in it's current state, and a restore simply restore it in it's current state.

Now the reseller is notified there's an error and the email account wasn't backed up.

Why can't the reseller simply be notified that there's a mismatch but the user was backed up anyway?

This problem has already cost us an entire day's worth of work ; I have a great stake in seeing it changed .

Thanks.

Jeff

 

[DirectAdmin Support]

Hello,

Ok, I'll look into it. The main reason it does what it does is because the backup system was first designed for Users to use themselves. It was later adapted for Resellers to use for their Users. When a User restores himeself, he has to be limited, but I agree that the default state should be restored as is regardless of the limit if the Reseller is doing the restore.

John

 

[matrixx]

Surely if the package description the user had at setup was switched to custom IF it had gone over the quota when the resellers userpackage definitions were downgraded it would both restore as it should do and keep the user limitations.

Rob