Backup problem: file too big?

[tino]

Hi,

It appears that my backups are failing because the backup of one site is just too big. (8GB) The backup runs fine until this file gets transferred.

With Ensim, you can split the tar files into managable pieces (lik 250MB or so). This prevents these problems.

The error message I get in the "message system" is:

Subject: An error occurred during the backup. Today at 20:55
User user1 been backed up.
User user2 been backed up.
User user3 been backed up.
User problem has been backed up.
User user4 been backed up.
...etc for each user. now the transfer starts:...
Error while uploading problem.tar.gz

Is there a way to work around this? Will there be a fix for this? Noone else has problems with large sites?

Tino

[DirectAdmin Support]

Hmm.. is it possible to just run the backup locally and ftp the file manually?

John

[tino]

Well,

could be, but I'd rather have an automated solution.. :-)

Where are the files located when I setup a backup job that ftp's to another server? Will these files be kept after a failed transfer?

for now, I'll make a local backup and try to transfer it through ftp, just for testing.

Tino

[DirectAdmin Support]

Hello,

They're put in /home/tmp/resellername/* .. but removed after the backup attempt, regardless of outcome.

John

[tino]

Okay,

I've backupped the site (that went well), and I'm manually ftp'ing it to another server. It's pretty fast, but it's 23:45 over here, so I'm not sure if I can wait for the upload to finish. It's past my bedtime already... :o

It's now at 2.2GB, and still going strong... Couldn't it be a php timeout error? I can remeber a setting in php.ini that sets a maximum to the time php scripts can run...? Backing up this amount of data will take at least an hour... Could that be it?!

Tino

[nobaloney]

2.2 Gig?

Many linux servers have a 2G limit on filesizes.

Could that be the problem on one of your boxes?

Jeff

[tino]

The 2GB limit is for the ext2 filesystem. I use only ext3 filesystems, so that's not the issue.

I've FTP'd the file manually, and that works. Yet, from DA it won't. Perhaps a php time-out issue or something?

Tino

[nobaloney]

Are you sure?

We've got a bunch of RHL7.3 servers running ext3 filesystems which had problems until we started breaking up our backup files into smaller pieces.

Jeff

[tino]

Yeah,

But you cannot do that from the CP.

Tino

[tino]

I still cannot perform a normal scheduled backup.

Does anyone else have this problems?

It must be due to large sites (10GB or so)

Tino

[nobaloney]

Are you having problems with a user backup, a reseller backup, or a system backup?

It appears as if your backup software is running up against the largest file size allowed by your OS.

Check your OS for file size limits and report back to us :) .

And let us know which backup you're having problems with.

Jeff

[tino]

I have this problem with a reseller backup, doing all users.

I am running RedHat 9 with all ext3 filesystems.

A local backup appears to work. So it's in the transfer part.

Tino

[nobaloney]

If the local backup works, then it may not be the file size.

But I'm not sure because I've not examined the backup code.

If the backup code makes one tarball for transfer to the other system, and if your OS has a 2 gig limit, and if the resulting tarball is over 2G, it might fail.

But the failure should mean not that it doesn't seem to work, but that you can't restore from it.

What are the symptoms?

Jeff

[tino]

After the backup ran, I get a status message.

The status message is built like this;

First a few lines with:

User userX has been backed up.

But after a few succesfull backups, the rest of the backups fail with this error:

Warning: ftp_put(): userY.tar.gz: Permission denied in - on line 31
Error while uploading userY.tar.gz

When I do a backup to the machine itself, so not using FTP, it works. And, when I then try to manually FTP these files to my target machine, it works as well.

So it's not the target machines FS that's causing the problem.

Tino

[nobaloney]

Originally posted by tino
Warning: ftp_put(): userY.tar.gz: Permission denied in - on line 31
Error while uploading userY.tar.gz
What does line 31 of the backup program say?

When I do a backup to the machine itself, so not using FTP, it works. And, when I then try to manually FTP these files to my target machine, it works as well.
But perhaps you're doing it differently.

I'm sorry I don't have a better answer; perhaps DA support needs to get involved, though I'm not sure how they could help either; it may not be a DA problem either :( .

Jeff

[nobaloney]

Originally posted by GXX
My issue is, it does a local full system backup just fine. I can see the directory and all files in it. It just does not FTP it over to another server when it's done.
You may have incorrect settings somewhere in your backup ftp configuration.

Can you ftp the backup manually? If so, make sure your settings are the same as what you do manually.

I'm sorry I don't have any better ideas.

Jeff

[tino]

This is the code causing the problem:

if (ftp_put($conn_id, $ftp_remote_file, $ftp_local_file, FTP_BINARY))
{
exit(0);
}
else
{
echo "Error while uploading $ftp_remote_file";
exit(4);
}


My idea is that it has something to do with the $conn_id. Perhaps the connection server timed out or something because TARring the HUGE file takes some time;

DA uses $conn_id = ftp_connect($ftp_server);

I will try to change it into:

$conn_id = ftp_connect($ftp_server, 21, 600);

(in this case, the timeout is 600 seconds in stead of the default 90.)

Of course, you can also use ftp_set_option() and ftp_get_option() to change this value.

I surely would like DA to confirm this.

Tino

[nobaloney]

90 seconds seems much to low for me. I'd go for at least 10 minutes; perhaps 15.

As I've mentioned previously, the forums are NOT an official DA support venue; you could always send them an email :) .

Jeff

[nobaloney]

Can you use passive ftp?

It could be a firewall issue if you can't use passive ftp.

Jeff

[tino]

Since it always fails starting at the same domain, I don't think passive FTP is the problem.

Tino

[netmotiv8]

Originally posted by GXX
My issue is, it does a local full system backup just fine. I can see the directory and all files in it. It just does not FTP it over to another server when it's done.


Yes, we have exactly the same problem. Only one of our customers backup files are over 2Gb and that is the one which the FTP keeps failing on.

We really dont want to seperate this customer's backup out and generate a manual method as this creates an administrative nightmare.

Any one got over this problem yet, cos its a right pain in the ass!

Neil :-)

[nobaloney]

Some OS distributions can't handle files over 2GB.

What OS distribution are you using/

Are you using the sytem backup or the reseller backup?

If the system backup have you tried setting DA to upload each file as it's created? That might help by not building one huge file. Worth a try.

Jeff

[netmotiv8]

We are on RHEL3

Neil :-)

[nobaloney]

Googling finds that the maximum file size for an ext2 system is 2GB, and that an ext3 system is the same as an ext2 system, but with journaling added.

By default, CentOS systems use the ext3 file system, so it's logical to presume the problem is file sizes over 2GB.

Have you tried copying each file as it's created, as mentioned in my last post?

Jeff

[netmotiv8]

Originally posted by jlasman
Have you tried copying each file as it's created, as mentioned in my last post?

Jeff

Not yet, how do you do this in DA?


Neil :D

[netmotiv8]

Ah I see how you do it as admin user but we do this under the reseller user

Neil :D

[nobaloney]

As far as I know you cannot do it as a reseller user.

I did a bit more research after my last post; it appears that while Linux itself, and both the 2.4 and 2.6 kernel, can create files much larger than 2GB, the libaries compiled into most linux systems cause the 2GB limit.

Jeff

[netmotiv8]

It looks like this issue was fixed with DA version 1.26.1? can someone confirm this as it wasn't mentioned in the release notes.

We updated DA on 25.12.05 to v 1.26.1 and since then the ftp on the backups has not failed on files over 2Gb.

No other updates where done at that time (e.g. apache, php, redhat) so it was definitely something in the release of 1.26.1 that has made this work. We had updated Apache to v1.3.34 and PHP to v4.4.1 a few weeks before.


Neil :-)

[nobaloney]

The 2GB limit will occur sporadically, depending on your OS distribution and the way files on it were compiled against certain libraries.

I'm sorry I can't be more specific.

You may never have a problem, but you may.

Jeff

[netmotiv8]

I dont know about sporadic. The 2Gb issue has been consistent every day (we backup customer files daily) for last 6 months or so since some customers backup files exceeded 2Gb, then since the DA 1.26.1 update no more ftp failures on those accounts exceeding 2Gb.

I guess time will tell.

Neil :-)

[Protollix]

I use RHEL 3.0 w/ ext3 on my main shared server. No 2GB file size limit, however I backup remotely to a backup server provided by The Planet. They do have a 2GB file size limit.

So what I ended up doing was have DA do a system backup to a staging area on my local disk. Then I have a shell script run through cron a few hours later that tars up the backup directory and splits it into 1.5gb files, then copy that to my network share(backup drive on the The Planet provided server). Works like a charm now that I have all the bugs worked out...

Anyhow, when I was doing Reseller backups directly to ftp, I was getting the same error with files larger than 2gb..

[nobaloney]

$ man split

:)

Jeff

[roarkh]

The update to DirectAdmin version 1.26.3 did not fix the upload problem for me here. I run DirectAdmin under CentOS 4.1 and am trying to backup to an Apple Xserve G5 running Mac OS Server 10.4.5.

If I have DirectAdmin backup to a local directory and then manually ftp the files over everything works just fine, when DirectAdmin tries to automatically send the files using scheduled Reseller level backups it fails on any file over 2gb.

The fact that performing the ftp manually works seems to indicate to me that the problem is some sort of bug in DA. Am I wrong in my thinking here? Has anyone found a solution for this problem yet?

Thanks.

[wdieke]

Same problem here. I have a customer with 5+ gigs of photo's and the backup fails (the backup server is indeed an ext2 filesystem). I would urge to fix the backup code for DA to allow multiple volumes

[roarkh]

I believe that the problem we are experiencing has to do with the fact that php does not support file sizes larger than 2gb. This limitation appears to exist whether the machine it has been installed on supports larger than 2gb files or not. See http://bugs.php.net/bug.php?id=24411 for a bit more info on this.

The DirectAdmin script that is failing is located in /usr/local/directadmin/scripts and is called ftp_upload.php.

I have rewritten it on my system using a shell_exec command that calls curl to ftp the file instead of using php's built in ftp support and my backups are working again.

I would be happy to post the script if someone wants to see it but won't take any responsibility if it messes up your system (I am quite new to php). Also, since I am always backing up to an ftp server that uses PASV I didn't bother to have the script retry without it if the upload fails as the current DirectAdmin supplied script appears to do (I am both the admin and the only reseller that uses this particular server so I can get away with this kind of sloppiness).

[transix]

http://help.directadmin.com/item.php?id=111


works perfectly

cp ftp_upload ftp_upload.save

past the nftp part into the file and done.