Backing and restoring the store...

[JRR]

One thing I see very little information on is backing up and restoring a store. I have attempted to use the admin backup operation of OSCMax (and OSCommerce) to save a store I am building, but when I break the store (after backing up) I am unable to restore it to the previous iteration.

Note that I attempt to do this restore after erasing and reinstalling OSCMax subsequent to getting a white screen or nasty error messages.

I have been successful using the EasyPopulate function to restore the items for sale, but the restore function does not seem to restore the store at all...taxes, store name, location, etc. - all are lost.

I can probably do a backup using my ftp system, but was expecting that the built-in backup did an better and easier job of it. I haven't found much in the wiki on backing up either...it SAYS backup often enough, but really - an explanation would help those of us who expect a backup function to actually do a backup of the store setup would be helpful. Or am I missing something (as usual with OSCxxx)?

As a bit of personal history, I've been working with computers since I first built one back in the 70s (had cassette tape loading Basic) and have used DOS, DRDos, W2, W3.1, W85, W98, ME, XP, and now OSX and in almost all cases they actually explain HOW to backup, and what that backup actually needs to consist of to be able to restore the system. Oh, and I've run my own web site since 1996 - do the html coding with Dreamweaver (started with Frontpage).

Probably more information than needed but I don't want folks to think I don't know what a backup is!

Now I am no expert with PHP, not even close, but some explanations really need to be expanded.

John :-#)#

[JRR]

As an addendum, I have looked into the .sql backups and the information is there, however when i do the restore none of it is entered into the store. Are there permissions that need to be set before doing a restore?

Also where would I find the log or errors log file if the program is not able to install the backup to the catalog/store?

Thanks!

John :-#)#

[ridexbuilder]

[I've been drawing pictures since I was a kid - doesn't make me an artist. Loads of folks try to run their computer-based (e-commerce) systems without any real foundation to what they are doing.]

Backup within Admin clearly says it's a database backup - not a store backup, which will vary depending on how well/poorly the server environment is setup. Also, on whether a 'proper' server OS is used.

You could use your own experience to write a comprehensive wiki document. [I have more pressing needs for my thoughts/time than basic computing skills - Google for creating effective backups, for your chosen OS/server environment.]

Note: I run automated nightly cPanel backups (through cron) for my clients and store a copy 'off-site' from the server, with archives going back up to three months. No messing with Admin. backups or Easy Populate.
Job done.

[ridexbuilder]

As an addendum, I have looked into the .sql backups and the information is there, however when i do the restore none of it is entered into the store. Are there permissions that need to be set before doing a restore?

Nope.

Also where would I find the log or errors log file if the program is not able to install the backup to the catalog/store?

Depends on whether Admin restore or native mySQL restore is used (within phpmyadmin, for example).

[michael_s]

You may also have found a new bug in the system, since this is a new release. A bug could have been introduced. I will be testing it out shortly to see if I can track down a common problem. If so, I will report it in the tracker.

A good idea is to use your servers/control panels built in backup systems for doing backups, since server/account level backups are always more comprehensive than script level backups.

[JRR]

Nope.

Depends on whether Admin restore or native mySQL restore is used (within phpmyadmin, for example).

I used Admin restore - trying to restore the tax modifications, etc. to the PHP files. When I run Restore (under OSCMax Admin) it says "do not interrupt the restoration process." and this message simply doesn't change. Idid find a difference between backups.php for 2.0.15 and 2.0.3 - line 358 appears to be much shorter.

Version 2.0.3 line 358 is:

td class="pageHeading" align="right"><?php echo tep_draw_separator('pixel_trans.gif', HEADING_IMAGE_WIDTH, HEADING_IMAGE_HEIGHT); ?></td>

while the 2.0.15 line 358 is:

<td class="pageHeading" align="right">&nbsp;</td>

This is the only difference between the two files. Substituting version 2.0.3's backups.php does not change the result of no restoration actually done though so I do not think the change is serious...

I have set up CRON to do a daily backup but it seems to me that the Admin backup/restore should work properly...

John :-#)#

[ridexbuilder]

Idid find a difference between backups.php for 2.0.15 and 2.0.3 - line 358 appears to be much shorter.

Version 2.0.3 line 358 is:

td class="pageHeading" align="right"><?php echo tep_draw_separator('pixel_trans.gif', HEADING_IMAGE_WIDTH, HEADING_IMAGE_HEIGHT); ?></td>

while the 2.0.15 line 358 is:

<td class="pageHeading" align="right">&nbsp;</td>

This is the only difference between the two files. Substituting version 2.0.3's backups.php does not change the result of no restoration actually done though so I do not think the change is serious...

Got nothing to do with it! Does "pageHeading" not give you a clue as to the function of this line?

[michael_s]

I have set up CRON to do a daily backup but it seems to me that the Admin backup/restore should work properly

I agree, but there is more than one way to do a backup, so as a workaround, do as I suggest and continue backing up with your hosting account backup options.

Could you post some of your server config settings. OS, Web server and version, mysql and version, php version and whether cgi/suphp or dso).

I would like to try to reproduce the behavior, but I need your setup details first.

[JRR]

Is this what you are looking for..."Could you post some of your server config settings. OS, Web server and version, mysql and version, php version and whether cgi/suphp or dso."

OXCMax 2.0.15

HTTP Server: Apache/2.2.14 PHP Version: 5.2.12 (Zend: 2.2.0)
Server OS: FreeBSD 7.2-STABLE Database: MySQL 5.0.90-log

Configure Command: './configure' '--with-apxs2=/usr/(userdirectory)/apache/bin/apxs' '--with-config-file-path=/usr/local/etc/php5' '--enable-magic-quotes' '--enable-bcmath' '--with-zlib-dir=/usr/local' '--with-gd' '--with-freetype-dir' '--without-msql' '--with-mysql=/usr/local' '--with-mysqli' '--with-pdo-mysql' '--with-iodbc' '--enable-inline-optimization' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--without-recode' '--with-openssl=/usr/local/ssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--with-xsl' '--enable-mbstring=all' '--enable-mbregex' '--with-bz2' '--enable-exif' '--with-gmp' '--with-iconv' '--with-pspell' '--with-libxml-dir' Server API Apache 2.0 Handler

I do not know where to find out about the portion of your question relating to "cgi/suphp or dso?". Does this help:

Server API Apache 2.0 Handler
Virtual Directory Support disabled
Configuration File (php.ini)
Path /usr/local/etc/php5
Loaded Configuration File /usr/local/etc/php5/php.ini
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519


John :-#)#

[JRR]

Crap...it appears the reason that restore wasn't working for me was entirely my fault.

I really didn't understand how the store (Catalog) and the Database interacted. I thought the Catalog Admin backup and restore was working on the structure that was stored on my web site store Catalog - I didn't realize that the backup/restore file is the PHP file that the Catalog writes to Database. I made the assumption that because images, were being stored in the Catalog, that it followed that the tax info, manufacturers, store name, and other variables were ALSO stored in the Catalog directory. Foolish mistake! They are part of the Database located on the Database Server.

So what I was doing was backing up various PHP Database Server files I had created (for several test stores - Database x, Database y, etc.) and I figured I could simply use any of these backups with any store I created as I had assumed (I should know what ASSUME means by now!) I was only changing the settings in Catalog and it wouldn't matter. Instead what I was doing was bending the PHP Database file enough that Catalog couldn't work it any more.

However I did discover that if I restore the CORRECT PHP Database backup (from the correct Database Server (say Database Server X backup restored to Database Server X) then the bent Database (store_data) would again work.

A solution to this, if you are experimenting with multiple Databases, is giving the backup files some of the name of the Database Server to avoid using the wrong Database Server files during restore.

Thanks to all who tried to help...

John :-#)#