Reseller (and user) backup fails, spaces in path

Laurens

New member
Joined
Sep 23, 2011
Messages
4
# cat /etc/redhat-release
CentOS release 5.6 (Final)
# /usr/local/directadmin/directadmin c | grep -i 'version='
version=1.38.4

There is 1 user on a shared server (hosting a lot of other users, which all seem fine) whose backups won't succeed.

DirectAdmin says the job is scheduled succesfully. The backup starts as expected (yes, crond is running and doing fine). The backup process halts, what seems to be, at random. The 'backup' folder which is created in the users's home directory always has a different filesize (from 30 MB to 120 MB).

Running them as a reseller, through Admin Backup, yields the same results.

After further investigation, I noticed the backup-process always halts on the following tar process:

Code:
/bin/tar czfp /home/arganlife/backups/backup-Sep-23-2011-1.tar.gz  -C /home/arganlife/backups backup -C /home/arganlife/ domains > /dev/null

The paths "/home/arganlife/backups backup" and "/home/arganlife/ domains" concern me; note the spaces (a slash is 'replaced' by a space in the first path, in the second path a space is added before 'domains').

The command on its own hangs as wel, when I run it.

I would guess that those spaces are added somewhere by the DirectAdmin backup code. I'm not a hardcore developer, so I guess I won't be able to debug this myself.

Is there anybody who experienced the same problem? Would someone be able to give some pointers? I would like to know the answers to these questions before I contact DirectAdmin support (which have always been great to me, though!).
 
(Forgive me for this reply, but it seems that I'm not able to edit my original post?)

What I forgot to mention; the stated DirectAdmin version is indeed not the latest one. I checked the changelogs however, and I could not find any mention of a bugfix that addresses the problem I'm experiencing.

Thanks! :)
 
The DA Message system doesn't return any errors at all;

Subject: Your backups are now ready
Body: Backup created

/usr/local/directadmin/error.log says the following;
2011:09:28-14:31:01: File ./data/users/arganlife/user.usage has been written to after this process read it. Not going to overwrite it.

This message is returned on other backup jobs as well, and they appear to finish successful.

I haven't tried debug mode, but 'if all else fails' it is my last resort though.

I'll let my boss know about your offer :) although I can't at all assure that he would be willing to make use of it.

Thanks for the help so far!
 
A follow-up on this issue, from myself;

"Miraculously", I've been able to take a user backup from the user's account.

There haven't been any changes to the system whatsoever. I already suspected bad user data (e.g. a corrupt database or something, there just weren't any logs confirming this) since the account was the only one on the server suffering from the issue. And now, suddenly, after a couple of weeks, it's yet again possible.

Bottom line; make sure that the client data is ready to backup (databases, permissions, ...).

Thanks to all for reading and thinking along :)
 
Back
Top