Finding out the hard way that restore doesn't .. advise please

[JWCravers]

We have an admitedly large OSC store on a hosted virtual server. We have been doing database backups via OSC backup in admin. Unfortunately our ISP trashed the site and their backup of the server was found to be non functional. Thus we turned to our backups only to find that the backup files were quite large (300-600 megs), wouldn't open, and were incomplete to boot. After weeks of manually rebuilding what we could we are largely past this immediate problem.

 

However, aside from the obvious issue of looking for a reliable, smart ISP (good luck on that one!) we are faced with having learn more about reliably backing up our databases. Please, any reliable advice is appreciated. The current OSC backup looks to create an SQL script file that rebuilds all tables, properties, and data. If these are just text files why are they so large and still incomplete?

 

Should our backup procedure be different because we are using a virtual server by an outside ISP?

 

Is there a good reason to buy two sites via different ISPs and copy data from one site to another? Then should a problem arise we could maybe send customers to the backup site should a problem occur? More and more it seems that these ISPs are unapolgetic about their responsibilities in backing up, providing uptime, etc. We have been hosting on AIT.

 

Thanks for any well reasoned responses

[Guest]

You are right about the size.sql should not be more that few hundred keys.It is a text file.Does the extension said *.sql or different.

[Jack_mcs]

We have an admitedly large OSC store on a hosted virtual server. We have been doing database backups via OSC backup in admin. Unfortunately our ISP trashed the site and their backup of the server was found to be non functional. Thus we turned to our backups only to find that the backup files were quite large (300-600 megs), wouldn't open, and were incomplete to boot. After weeks of manually rebuilding what we could we are largely past this immediate problem.

 

However, aside from the obvious issue of looking for a reliable, smart ISP (good luck on that one!) we are faced with having learn more about reliably backing up our databases. Please, any reliable advice is appreciated. The current OSC backup looks to create an SQL script file that rebuilds all tables, properties, and data. If these are just text files why are they so large and still incomplete?

 

Should our backup procedure be different because we are using a virtual server by an outside ISP?

 

Is there a good reason to buy two sites via different ISPs and copy data from one site to another? Then should a problem arise we could maybe send customers to the backup site should a problem occur? More and more it seems that these ISPs are unapolgetic about their responsibilities in backing up, providing uptime, etc. We have been hosting on AIT.

 

Thanks for any well reasoned responses

I'm confused by your use of ISP. I assume you mean your host. No matter though, a database that size would not be restorable on any shared server using the admin tool. You will need to backup using your hosts control panel option. Although I would first look at the contents of the database. That is a very large one and I would be surprised to find that there wasn't data in that that was not needed. And while it is probably too late now but my guess is the backup done by oscommerce was good. It was just that it couldn't be restored that way. Restoring using phpmyadmin would have probably worked.

 

Jack

[JWCravers]

You are right about the size.sql should not be more that few hundred keys.It is a text file.Does the extension said *.sql or different.

 

It's .sql, not a txt file. However opening it from a text editor seems to be the only way to get it open.