System requirements for FTP backups?

S

Saeven

Verified User
Joined
Jun 29, 2003
Messages
76
Hi guys,

I have two DA servers, on one of which everything works like a charm. On the other unfortunately, the FTP backup is not working at all; I'm sitting on the FTP server console, and there's not even a peep as far as connections go.

The DA system backup log reports:

Dumping database zolea_scrm: Completed
Performing backup transfer to 99.x.x.x: Completed
Performing cleanup operations: Completed
Click to expand...

But this cannot be true! Is there a fail log anywhere?

I can telnet on port 21 to the FTP server from the affected DA machine, so I don't suspect that this is a connectivity issue at all.

Thanks as always.
Alex
 
Alex, you don't say which kind of backup you're attempting.

I seem to remember some posts in these forums that mentioned similar problems; perhaps a search will help you find the response.

There's no fail log. There's no log for outgoing messages from ftp.

Which backup system do you mean? If you use sysbk, I don't think it uses standard commandline ftp; you might want to check what it uses.

If you use one of the otherbackup facilities you might want to check with DirectAdmin staff.

Jeff
 
Hi Jeff,

Good to hear from you again. It's the standard "System Backup" menu from the admin section, that lets you specify an outgoing FTP address.

It claims success, where no transfer or connection even takes place...

I did search the forums, most of the posts I found had to do with reverting to a "previous" method, which I tried - or people venting and then being suggested to use rsync instead without a solution otherwise. I have to note that the machine that works, is on 1.28, whereas the broken one is on 1.3... perhaps something happened along the way?

Cheers.
Alex
 
Alex I'm sorry it's taken me so long to respond.

The original sysbck code never did properly check to see if ftp worked properly or not; Personally I've always run a script on the backup machine to check and email me <frown>.

Now we're switching to use the new Admin Reseller backup which so far, at least, appears to be working properly.

Have you checked to see if you can do a backup from the command line, to the backup machine?

Now that the new backup (more granualar, and much easier to restore) is finally a finished piece of DirectAdmin code I'm not sure anyone will want to work on sysbck.

You might want to try the new code and see if it works for you.

Jeff
 
I've turned off sysbk, and will give the new system a shot! Is there a means to trigger it from the command line? I'd like to see if any errors are being spit out...

Right now, issuing a "Backup now" from the web interface, yields no expected results...

Thanks again for your continued assistance! I hope that this thread helps others as well!

Cheers & Thanks,
Alex
 
Ok. Here's an update... The backup doesn't work, but I'm at least getting this type of error message (per user) in the logs:

Cannot open local file /home/tmp/admin/user.admin.bright.tar.gz for reading: Permission denied.
ncftpput /home/tmp/admin/user.admin.bright.tar.gz: could not open file.

Unable to write /home/tmp/admin/brun/backup/support.xxxx.net.au/email/passwd : Unable to get Lock on file
Click to expand...

... ad nauseam


The ftp_upload script is owned as follows:
Code: 
-rwx------  1 diradmin diradmin   364 Jan 21 21:21 ftp_upload.php

Permissions issue? Not sure who runs the CRON, or what the home/tmp folder should be owned by. Right now, it is owned by root/root.
 
Do you have /home/tmp ? Make sure it's chmod to 1777.
Also, to clean it up, make sure it's totally empty of all files if no backups are being run. Delete any directories if they're left behind.

John
 
Thanks for the response John.

Yes the directory exists. ls -l from /home reveals:
Code: 
drwxrwxrwt  2 root      root      4096 Feb  7 05:34 tmp

It is entirely empty. The aforementioned errors continue.

Regards.
Alex
 
You must log in or register to reply here.
Back
Top