Backup is to big

I have bumped those settings to 180s and still no luck.

When I click the ASAP backup it tells that it will be done for example at 15.46 – the file time stamp shows that it was finished at 2015-09-11-154633.zip if I understand it correctly – 33 seconds – or I misinterpret something here ??

One way or the other I have checked it before 3 minutes passed. As this is a VPS and the data base is tiny (I’m checking it on an other site with exactly the same settings as the big one – I don’t want to experiment on the production environment) it was done very fast. The backup folder has only wp-content and wp-config.

@infolotnicze – do a small backup of a small amount of files by excluding everything else to make sure DreamObjects Backups is working and that will also tell you if there is a size issue.

General help info:
max_execution_time is basically the time it takes to process a particular function and is not the total time allowed to do anything. This directive is a bit confusing especially when you factor in set_time_limit(): https://php.net/manual/en/function.set-time-limit.php
Recommended Setting: 30
Description: This sets the maximum time in seconds a script is allowed to run before it is terminated by the parser. This helps prevent poorly written scripts from tying up the server. The default setting is 30.

mysql.connect_timeout is basically just the connection handshake and is not the total time allowed to do anything.
Recommended Setting: 30
Description: Connect timeout in seconds. On Linux this timeout is also used for waiting for the first answer from the server. The default setting is 60. If you are debugging code you should set this to 3-5 seconds.

Also in general when doing file backups you usually do not need to backup everything. The logic for what to exclude from a backup is things that are easily replaced. WordPress folders/files are easily replaced by uploading a new WordPress version or just reinstalling WordPress itself.

AITpro, he’s actually tested with just the SQL db alone, so it’s not the size (unless he’s wrong about the SQL DB being 110 mb). The DB is just … not exporting. It comes down as 0kb.

All I can think is something might be stalling the DB connection.

Oops my bad. Coffee had not fully kicked in yet. ?? I see that you already had him test that too. This info is not correct for max_execution_time: “The default setting is 30.” The PHP default setting is: 60 not 30.

@infolotnicze – to completely eliminate BPS as causing a problem turn everything off in BPS. See the BPS forum troubleshooting steps if you are not sure how to do that.

hmm looking at the code in file: dhdo.php I see several exec(); functions being used, which could be a problem on some servers. These days I see more and more hosts automatically disabling the exec() function. Your logging looks very extensive and checks every point very well so it should pinpoint a problem. I will signup in a bit to actually test things.

Also for manual testing purposes I guess unlink could be commented out to see if the dump is being created to further isolate what is going on, but since your logging is so extensive then it should already pinpoint a problem without having to do that.
//@unlink($sqlfile);}

Another thing I noticed is that I do not see any backticks being used. I ran into a problem with that in BPS DB Backup where folks used unusual naming conventions for DB Tables.
Example: $build_query_1 = "SHOW TABLES FROM“.DB_NAME.”WHERETables_in_”.DB_NAME.”LIKE '";

The backticks were stripped out of my post above of course. ??

Hmm the unlink thing got me thinking that maybe the unlink is happening before the dump can be included in the backup? Possible and for whatever reason I have a gut feeling that it may be going in the right direction. ??

Yeah, I work at DreamHost so I know WE don’t kill exec!

The default PHP exec setting depends on hosts too, but yeah, 60 is normal. I have to admit, I’ve never seen a plugin require all those in the wp-config before. Not all hosts let you set the PHP stuff like that (PHP is such a fickle beast ?? )

Yep, in a lot of cases I end up having to dumb code down to make sure it works on the widest possible range of Hosts. Painful, but necessary or you can always write double code if you still want to show off your “cool” code vs your dumbed down code. ??

Yep, a Host can always silently ignore anything it wants to ignore. ??

And this is a perfect example: We recently created htaccess code for forward|backward compatibility with the newer Apache Modules: mod_authz_core and mod_authz_host. When we started out on that project it looked like a piece of cake. What we did not expect to find was a significant number of Hosts do not support (or maybe a misconfiguration) this IfModule checking condition: IfModule mod_authz_core.c. Yeah talk about a huge monkey wrench. ?? End result massive amounts of failsafe (dumbed down) checking code needed to do something that should be a one liner. It’s great when everyone is on the same playing field. ??

@aitpro

The logs don’t show any errors. The only good thing is that BPS Pro makes sql backups and they are all stored ina a folder so when DreamObjects kicks in, it dumps the folder in which the BPS Pro sql dumps are stored.

I have no clue what is going on here and what to do next ??

Have you tried doing just a DB Backup without a file backup?

I just did a test and turned only DB backup and it gave an empty sql file.

Ok good that narrows things down quite a bit. I’ll keep this explanation simple: MySQL DB’s use backticks in Query code to ensure that whatever Query is being run will work without errors and problems. Of course I am keeping this very basic/generalized.
https://stackoverflow.com/questions/11321491/when-to-use-single-quotes-double-quotes-and-backticks

BPS DB Backup uses backticks in the Query code. DreamObjects Backups is not using backticks in the Query code. So if you have any unusual table names or fields or anything else that MySQL does not understand then that would cause the backup to fail and be empty.

I assume your database is a MySQL database correct?
What DB Engine are you using?
What is the name of your database?
What is your DB Table prefix name?
Are you using any unusual/non-standard naming conventions for database tables or fields?