when you restore from backup you need to create username?

psalm91

Verified User
Joined
Sep 20, 2015
Messages
168
I reinstalled my os and directadmin.
Before I do I backedup a site that I had.
after reinstalling I went to admin section to restore but the error says

Kd-backup-Aug-8-2019-1 is not a valid username

What exactly should I do to restore this?
 
Did you not use the Native Directadmin Admin Backup and restore in the Admin Panel?

Is this a User backup and not an Admin backup?
 
Kd-backup-Aug-8-2019-1 is not a valid username
This looks like a userbackup, should be restored via the user restore function.
So yes, you have to create a useraccount for this user and then restore this file from there. If it's a real userbackup from DA and not some self made thing.
At least that's the easiest way.
 
So yes, you have to create a useraccount for this user and then restore this file from there. If it's a real userbackup from DA and not some self made thing.
At least that's the easiest way.

Sorry for bumping the old thread. I think the user backup can be used to restore using admin backup section as well. I just compared the backup files between the user and admin backup and I found out they are identical. To restore, it needs to be renamed using a proper format like this (so DA can detect):

<role>.<creator>.<username>.<backup_extension>

eg:

user.reseller88.myuser.tar

Then put it in your admin_backups folder.
 
To restore, it needs to be renamed using a proper format like this
Did you test it? Because it might work that way, however, doing it this way, you will place the user under some reseller (or admin). The user is not known under the reseller/admin, so how will DA know which package the user will get? It might give some default package and you can change that later.

But that's why it's IMHO safer not to rename things, but just create the user with the appropriate package and then run the restore from the user account, which will overwrite the user settings (like password), but less chance something will miss.
Especially if you get a user backup from a customer who comes from another hosting company.
 
Yes, I just tested it and it works:

1636296450639.png


To get the creator, role, or username of the user backup the tip is to look at this file:

backup\user.conf and look at the variable values like this:

username=myuser # (the username)
usertype=user # (can be reseller, admin)
creator=reseller88 # (who created this user)

I think this works perfectly as the user backup in admin_backup tool section just uses the copy of the user_backup method. They are identical files (I have verified this with winmerge tool). @smtalk can verify if this is true whether there would be no issue if we can use user_backup in admin_backup.

From my understanding.. when doing restoration for any users, the most important thing is the creator of the user backup must exist in the system first and the creator must have created a package for the user if the backup contains domain. For example, looking at user.conf, the package is defined like this

package=USER_UNLIMITED

So, the creator must create a package with this name first. So, first choice 1) you either create a user and restore the backup on the existing user in the user backup tool section or second choice 2) if you want to restore using admin_backup tool then you have to make sure the backup has a proper name using the syntax above and with a few conditions like above (using this way you don't have to create a user first) but you must restore it using admin. The OP saw the error because DA restore did not detect valid file syntax for the admin_backup.

Also I think we can also use admin_backup file in user_backup section.
 
Last edited:
the most important thing is the creator of the user backup must exist in the system first
Correct. But mostly resellers have multiple packages. I'm wondering which package is applied to the user on restore. The first one? Probably but I'm just curious to that.

I do agree that restoring this way is possible. I'm only saying it's better/easier doing it via the "normal" way.
But it's good to know the structure of the files in case you have to rename them.

You might indeed be able to use an admin_backup file in the user_backup section, but that also needs renaming in that case. I've had an admin backup file in the user_backup section some time ago, and the user back/restore does not see that file or gave an error on restore (not sure anymore), so it also would need renaming.
But I don't see any benefit in doing such things except for in exceptional situations.
 
Correct. But mostly resellers have multiple packages. I'm wondering which package is applied to the user on restore. The first one? Probably but I'm just curious to that.

Haven't tested with resellers having multiple packages. I will update my post when I have time to test this. The benefit of doing this is not for all but for some people like me working with full admin backup automation. For example, I can check if a user who already did backup using user backup tool before and simply c̶o̶p̶y̶ link their backup to include in admin_backup. This will reduce the time to backup and avoid backup duplication. From my observation throughout trial and error, they are the same file structures and 100% identical. The difference is the naming convention.

The admin_backup is required to have file syntax as I mentioned.

I don't know why they don't just read the backup information from user.conf (that would be a lot easier without having to rename and OP will not have this issue like what he just saw)

If you notice, when you trigger admin_backup, it also actually call user_backup_pre and user_backup_post hook script individually to create backup. This also might be the hint that admin_backup is just like a wrapper to call that user_backup_pre/post script to create user backup. @fln can verify if this correct.
 
Last edited:
I can check if a user who already did backup using user backup tool before and simply c̶o̶p̶y̶ link their backup to include in admin_backup.
That might be an idea, but I wonder how you intent to automatically rename that backup when including?
User backups do not have the syntax admin or reseller backups are using. They only have a date, no username. So if you include those in admin backups, how do you know which user the userbackup is belonging to?

I think the reason they do not read the backup info from the user.conf maybe has something to do like how they created DA in the beginning. Maybe it has something to do with how DA handles it on restore when for example you have admins/resellers with multiple packages or to be compatible when restoring DA backups with other hosting party's, were a new account has to be created. I have no clue.

without having to rename and OP will not have this issue like what he just saw
I have some doubts that, when thinking about multiple admins/resellers or moving to other hosting services.
 
That might be an idea, but I wonder how you intent to automatically rename that backup when including?
User backups do not have the syntax admin or reseller backups are using. They only have a date, no username. So if you include those in admin backups, how do you know which user the userbackup is belonging to?

This can be done by reading the user.conf file inside the backup folder called backup/user.conf as the user.conf file has all the information about the creator, role, and username. If using bash script, this can be done by using the source command from user.conf file because they are all can be treated as variables. After we obtained all the information, then we can rename the backup file using mv command in the script:

eg:
# === userbackup convert to adminbackup ===
# must extract userbackup first if the backup is stored in tar
# source .../backup/user.conf
# remove the backup
# rename the userbackup file for adminbackup compatible backup file
mv Kd-backup-Aug-8-2019-1.tar ${role}.${creator}.${username}.tar

Those 3 variables came from user.conf

The above is just an idea for automatic conversion from userbackup to adminbackup (I haven't applied this yet but I think it will work just fine as manual method work too). Found issue: I do think the extracting part will slow down the process.

and when done move the backup file ${role}.${creator}.${username}.tar in the admin_backup section and you can restore this user.

PS: started to think that the userbackup conversion should be added as a feature request.
 
Last edited:
It seems an interesting idea as an addition to the existing backup method.

However, I'm just wondering about 1 thing. Is there a way to determine which kind of backup a user made?
Because a user can choose to create a full backup or only partly, maybe only database or only mail, or only website and mail and not the database. So this way you can get all kinds of different partial backups from users.

Is there a way to determine that? Because if I'm not mistaken, a user backup is always backup-<date>.tar.gz and not backup-<date>-<what is backked up>.tar.gz which could cause incomplete backups if user backups were just automatically converted.

Maybe that is the reason why DA choose this method, I don't know but it was just something which came to my mind.
 
bumping this thread.

how can we create "admin backups" when migrating clients from other provider?.

we can't. so there should be an easier way to restore a "user-generated" backup from the admin panel.
 
@Zhenmue create user->download user-generated backup to it's account -> restore it from user-level as own backup -> fix db/user-names/filepaths in website configs.
 
Back
Top