Help! What file(s) are the customer orders in?

I need to do a full system restore from a backup last week, but I really can't afford to lose all my customer order information/details/payments.

What files do I need to backup so that I can restore orders from the last week after I do the full system restore?

Thanks for any help! I'm desperate!

:frusty:

The orders are not in FILES, but stored in the DATABASE.

There are (fundamentally) TWO parts to a ZC website:-

1. FILES (including code, html, images, etc)
2. DATA (stored in tables in the database)

When backing up a site, you need to back up BOTH the FILES and the DATABASE.

fairestcape:

The orders are not in FILES, but stored in the DATABASE.

There are (fundamentally) TWO parts to a ZC website:-

1. FILES (including code, html, images, etc)
2. DATA (stored in tables in the database)

When backing up a site, you need to back up BOTH the FILES and the DATABASE.

I'm not a programmer, so I'm doing the best I can. :smile:

Let me explain a little more clearly.

I need to revert to a backup of my Zen Cart / site from last week. I've had sales since last week. When I revert to the backup from last week, I'll lose all of the info/details from those sales that have happened since then. I can't afford to lose that information.

So the question is, what database(s) do I need to backup right now so that I can plug all of the current job/sales info back in after the restore to last week's backup is completed?

Thanks.

Most hosts will permit users to invoke full backups (usually via C-Panel), but will not generally allow the website owner to do a "restore", from these backups. You will have to ask your host to restore the last backup for you.

... and yes, all data collected between the last backup and now - will be lost when you restore that backup. So if you last backed up a week ago, any data collected during the week has vanished into the ether.

I keep my sites with hosts that do a full, daily backup automatically. Yes, it costs me an extra $2 a month...

... but I have peace of mind!

fairestcape:

Most hosts will permit users to invoke full backups (usually via C-Panel), but will not generally allow the website owner to do a "restore", from these backups. You will have to ask your host to restore the last backup for you.

... and yes, all data collected between the last backup and now - will be lost when you restore that backup. So if you last backed up a week ago, any data collected during the week has vanished into the ether.

I keep my sites with hosts that do a full, daily backup automatically. Yes, it costs me an extra $2 a month...

... but I have peace of mind!

My host will allow me to do a restore, so again, that's not the issue.

My question is where are the databases that house the sales information, so I can restore the sales info from this week after the complete restore is done from last week's backup?

If your database is working, why do you want to restore it?

You are saying that you want to get this weeks sales data off the database...

... which means your database is not broken!

If your database is doing its job, collecting and storing info, then don't tamper with it.

It's like driving your perfectly OK car to the workshop to have the perfectly working engine replaced...

What exactly are you trying to "restore"? What has stopped working?

Furthermore, the "sales data" you refer to is cross-referenced in the database in a variety of very complicated ways, including session ID's, incremental ID's, customer data, dates, product info, reports, user stats.... the list is long...

How do you propose to restore just this weeks "sales data"?

This would be a huge job - even for people who know ZC's dbase structure very well!

Ok. Thanks.

Just tell us what has broken...

If there are problems with the FILES (the stuff stored in the FOLDERS in your ZC installation) then you can restore these FILES fairly easily - as long as they are the same VERSION as the original files.

Sometimes, these FILES get corrupted, making your store inoperative.

This does not mean the database has been damaged.

Before you overwrite anything, you must determine if the problem is a corrupted file (or files), or if the database is faulty.

Separate tests are required to establish whether it is a FILE problem or a DBASE problem.

When you have established where the problem lies, you then tackle it.

My advice is to be VERY CAREFUL about messing with the database, as fixing this is extremely difficult... especially if there's nothing wrong with it in the first place.

Again, describe your problem and we may be able to advise the best solution.