Database Backup. Simple Sql Dump?

I use the database backup feature very regularly and I found that it used to take some time to run (longer than PHP allowed for script execution on a shared server). For that reason I moved to a VPS. Everything is fine on the VPS but because I am not overly happy with the provider it has caused me to look into whether I can return to the previous 'shared hosting' environment. This is not for cost reasons, simply preferred choice of hosting provider. The only reason I moved was because of the backup script. Can anyone tell me if the backup script is simply a standard SQL dump that would be the same if initiated direct via phpMyadmin - or does the script do anything else that is not just a standard SQL dump? I was going to move to a dedicated with my preferred provider however they are very confident that the site is small enough to utilise their shared server (as I did before) and that a dedicated would be overkill. If I could just use phpMyadmin then that would be my preference.

[quote name='lwronline' timestamp='1408458683' post='189953']

I use the database backup feature very regularly and I found that it used to take some time to run (longer than PHP allowed for script execution on a shared server). For that reason I moved to a VPS. Everything is fine on the VPS but because I am not overly happy with the provider it has caused me to look into whether I can return to the previous 'shared hosting' environment. This is not for cost reasons, simply preferred choice of hosting provider. The only reason I moved was because of the backup script. Can anyone tell me if the backup script is simply a standard SQL dump that would be the same if initiated direct via phpMyadmin - or does the script do anything else that is not just a standard SQL dump? I was going to move to a dedicated with my preferred provider however they are very confident that the site is small enough to utilise their shared server (as I did before) and that a dedicated would be overkill. If I could just use phpMyadmin then that would be my preference.

[/quote]



CS-Cart makes the same backup as you can make within PHPMyAdmin. It is just collection of sql queries. Actually, it is strange that you decided change hosting because php has limits. Did you try just increase php limit settings?

A lot of the shared hosting companies, especially in the UK, do not allow the overriding of default script execution times so as not to allow individual users to dominate server resources. Now I know I can backup with phpMyadmin with no difference, it makes it easier, quicker and more convenient. I have seen a lot of people have this problem on the forum over time and have to move (in many cases t0 dedicated). IMO it would be beneficial for the script that does the backup to operate in stages, so that it is not a single script, reducing the likely hood of exceeding limits. “bite size chunks”. Step 1, Step 2, Step 3… etc etc etc.

[quote name='lwronline' timestamp='1408458683' post='189953']

I use the database backup feature very regularly and I found that it used to take some time to run (longer than PHP allowed for script execution on a shared server). For that reason I moved to a VPS. Everything is fine on the VPS but because I am not overly happy with the provider it has caused me to look into whether I can return to the previous 'shared hosting' environment. This is not for cost reasons, simply preferred choice of hosting provider. The only reason I moved was because of the backup script. Can anyone tell me if the backup script is simply a standard SQL dump that would be the same if initiated direct via phpMyadmin - or does the script do anything else that is not just a standard SQL dump? I was going to move to a dedicated with my preferred provider however they are very confident that the site is small enough to utilise their shared server (as I did before) and that a dedicated would be overkill. If I could just use phpMyadmin then that would be my preference.

[/quote]



Let me provide you with the simple trick


  1. Optimize your database at first
  2. Open the app/controllers/backend/database.php file
  3. Replace


fn_define('DB_ROWS_PER_PASS', 40);



with


fn_define('DB_ROWS_PER_PASS', 4000);



4. Try again. If you see white screen, decrease the value from 4000 to 1000



Now the database dump will be created faster, much faster

[quote name='eComLabs' timestamp='1408476899' post='189981']

Let me provide you with the simple trick


  1. Optimize your database at first
  2. Open the app/controllers/backend/database.php file
  3. Replace


fn_define('DB_ROWS_PER_PASS', 40);



with


fn_define('DB_ROWS_PER_PASS', 4000);



4. Try again. If you see white screen, decrease the value from 4000 to 1000



Now the database dump will be created faster, much faster

[/quote]

Wow! That seems like a good fix. Can't wait to try.Will that also work with restore? I ask as when I move server I will have to install and then import current database… would be very useful to know as that is another hurdle to get past with a move.

[quote name='lwronline' timestamp='1408477482' post='189985']

Wow! That seems like a good fix. Can't wait to try.Will that also work with restore? I ask as when I move server I will have to install and then import current database… would be very useful to know as that is another hurdle to get past with a move.

[/quote]



Try it and let us know the result. But unfortunately, this trick will not work with restore.

[quote name='lwronline' timestamp='1408476829' post='189980']

A lot of the shared hosting companies, especially in the UK, do not allow the overriding of default script execution times so as not to allow individual users to dominate server resources. Now I know I can backup with phpMyadmin with no difference, it makes it easier, quicker and more convenient. I have seen a lot of people have this problem on the forum over time and have to move (in many cases t0 dedicated). IMO it would be beneficial for the script that does the backup to operate in stages, so that it is not a single script, reducing the likely hood of exceeding limits. “bite size chunks”. Step 1, Step 2, Step 3… etc etc etc.

[/quote]



eComLabs provided you with great recommendation.



Did not forget change in app/controllers/backend/database.php also:


set_time_limit(3600);



to


set_time_limit(0);





and memory_limit in config.local.php to


@ini_set('memory_limit', '512M');



or more than 512M as you wish, to exclude script stopping.

Be careful setting set_time_limit(0). If you run a VPS, you might have to reboot to recover from an error. 3600 is 1 hr of CPU time (not wall clock time, but actual CPU time). If you have anything in your store that is going to chew up that much CPU then you have other problems.

[quote name='tbirnseth' timestamp='1408573172' post='190127']

Be careful setting set_time_limit(0). If you run a VPS, you might have to reboot to recover from an error. 3600 is 1 hr of CPU time (not wall clock time, but actual CPU time). If you have anything in your store that is going to chew up that much CPU then you have other problems.

[/quote]



Continuing this thought. Be careful and with memory_limit, script can eat up all available memory of server.