Backup System bug: custom public_html symbolic link handling

layer0

Verified User
Joined
Aug 3, 2006
Messages
68
Sometimes customers (especially some of the more 'savvy' developers) like to symbolically like public_html from another domain folder to something else. If we backup using DA and then restore that account, it'll restore without the custom symbolic links the user put into place. We then have to manually put them back into place (or create a script that does so). Can DA's system be refined to handle cases where customers do this? It would be most helpful.
 
Details, please.

Are you writing that no symbolic links are backed up? Or that symbolic to different domains aren't being backed up? Or that symbolic domains between users aren't being backed up?

Are they not being backed up at all, or are they backed up, but broken when restored?

Jeff
 
The bug is this:

User deletes public_html in ~/domains/domain.com

User creates something like ~/domains/domain.com/project/web

User symbolically links as such:

ln -s ~/domains/domain.com/project/web ~/domains/domain.com/public_html

Problem:

We backup user and restore them to the new server. Now they just have an empty public_html and no symbolic link. User complaints site is down, we need to re-add symbolic link.

Solution:

DirectAdmin needs to add a handler for whether public_html is symbolically linked, save it as such in the backup, and ensure that is restored when the package is restored to a new system.

Impact:

Causes havoc during migrations, especially among customers who lots of development work with such setups. We can script it on our end to check for it during migrations, but DirectAdmin should really handle it. cPanel is able to handle this just fine, by comparison.

Thank you.
 
Back
Top