Export command to back up data

Question

Dear All
I am developing a system for a store system, and I want to use the export command to let the user back up the data , but I have those four questions:-
1. Is using the export command a good practice for doing the back up process?
2. At what time in the day the customer should do the back up for his system?
3. let say he will do the back up at the end of each working day , then could he only back up the new data that have not been backed up before, or he always should back up all the data in the database regardless if this data were backed up before.
4. And if the user do a back up for his work at the end of each day then what will happen if the system crashed during a working day, will he lose the data that have been updated and not backed up before?

Answer 1

An export backs up the data, not the database. That's the fundamental difference between a 'logical' and a 'physical' export. Instead of copying files (from disk to disk or disk to tape), you are selecting out the data that has been previously inserted into the database.
There's nothing wrong with that as such, but it doesn't scale: selecting out 100 million rows is going to take about 100 times as long as selection out just 1 million. That's why you heard that export was OK as a backup mechanism for small databases: for large databases, it's a non-starter, simply because it would take days to select all the data out (and even longer to insert it all back again). On the other hand, physical backups do scale to a certain extent, because a lot of data files are mostly empty space for a lot of the time. So a 100GB database could probably be storing 1 million rows or 10 million rows or even (at a pinch) 100 million rows: data files don't grow every time you insert a new row, in other words. So almost regardless of how much data you are storing in the database, the time taken to back it up isn't going to vary that much. (There will be periodic points, of course, where you fill all available space and make the database jump in size by an increment... but between two of those points, you can keep piling the records in and the database size won't change).
So that's one thing: export doesn't scale.
Second big thing is that once you start dealing with rows of data, you've completely lost the ability to recover things using Oracle's entirely physical recovery mechanism. That is, with a physical backup of a datafile made on Sunday night, and a record of all the changes done to data on Monday, Tuesday and Wednesday (called redo), if I lose a datafile on Thursday morning, I can restore that one file from Sunday's backup, replay all the data changes in the redo stream and get my entire database back up and running exactly at the point it had gotten to when the datafile was damaged. That's called a complete recovery and it is such a reliable and robust mechanism that you are guaranteed not to lose any committed data using it: you get everything back (so long as you keep all your redo since your last backup).
But that guarantee only applies when you are taking physical copies of data files and storing redo in physical redo logs. If, instead, you are storing rows of data in export dump files, then that mechanism doesn't apply to you at all.
So, if you export a big table on Sunday, do lots of transactions to it on Monday, Tuesday and Wednesday, and then accidentally drop or damage the table on Thursday, the best you can do is import the table from Sunday's export... and that is it. You cannot apply the Monday, Tuesday and Wednesday redo to that restored table data. You cannot roll the table forward in time. Therefore, you lose all the committed data that was entered into that table on those three days.
Export is, in other words, a snapshot technology: you have replicas of your data as they were at some point in the past. You can always "restore" that snapshot, but that is as good as the recovery gets.
That's a big issue. It means that if you care about your data at all, or at least value it enough not to want to lose any of it, you cannot rely on export as a way of backing it up. If export is your only backup mechanism, you will lose data. That's a promise, incidentally: it absolutely will happen one day. It's not a 'maybe', just a question of time.
If you only did physical file copies, though, you would not lose data (again, always assuming you look after that stream of redo).
On the other hand, there are times when you positively want to extract data out of one database and re-insert it into another -such as when you decide your database was created using the wrong block size, for example. In those circumstances, physical backups don't help (because they simply copy the 'wrong' block size around the place). But an export does exactly what's required: separating the data from the physical files its normally stored in, and so is very handy for that sort of situation. Similarly, if I need to preserve one table for audit purposes, copying the entire 16GB data file in which it's 1000 records are stored is not a very efficient way of doing that! The fact that export works on an object-by-object basis, rather than a file-by-file one, means it's perfect for that sort of data extraction job.
Think of export, therefore, more as a system utility that happens to involve copying data. Yes, a copy can come in handy when disaster strikes and all else fails, but that's not its principle purpose. It might be sufficient functionality to provide the level of data protection you need, but it doesn't and cannot provide complete data protection, because it lacks that essential 'roll-forwardability' that physical backups (datafile copies) have.