Pau Lo
asked on
Importance of file system backups on DB servers
Can you explain something probably pretty basic in relation to file system backups of database servers. We have a database server (oracle 11g), I am told the backup process is split into 2 parts. 1m, the file systems and operating system files are backed up using the default windows server backup tool. The second part is RMAN is used to backup the actual database.
The DBA has a set routine to test restoring the database once per quarter, but they don’t test restoring the file system/OS backup. I think they also mention if the backups don’t work its just as easy to rebuild the server. Aside from the database on a database server, what other files may you need to restore? How important is the file system/OS backup of the database server, in relation to the backup of the actual database. What is the risk if the file system/os backup cant restore but the database can? Please keep your answers very low tech and basic.
The DBA has a set routine to test restoring the database once per quarter, but they don’t test restoring the file system/OS backup. I think they also mention if the backups don’t work its just as easy to rebuild the server. Aside from the database on a database server, what other files may you need to restore? How important is the file system/OS backup of the database server, in relation to the backup of the actual database. What is the risk if the file system/os backup cant restore but the database can? Please keep your answers very low tech and basic.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
So all in all a working backup of the file system/os files is still vital?
Can you give any examples where on a database server, aside from the actual database backup - the RMAN backup file, where you have had to restore other files, just to put it into some context.
Can you give any examples where on a database server, aside from the actual database backup - the RMAN backup file, where you have had to restore other files, just to put it into some context.
>>So all in all a working backup of the file system/os files is still vital?
It depends. There is no right or wrong answer here. It boils down to what information contained outside the database can you afford to lose?
For example, do you need to maintain the database/listener logs or windows event logs for auditing purposes?
If you have database auditing turned on, is it logging to the file system?
>>where you have had to restore other files, just to put it into some context.
It depends on what all you are backing up with RMAN. Are you capturing the spfile?
I cannot remember the recoveries I've had to do over the years so I'm afraid I don't have any real-world 'gotchas' you need to focus on.
Hopefully some additional Experts on the site can share some.
It depends. There is no right or wrong answer here. It boils down to what information contained outside the database can you afford to lose?
For example, do you need to maintain the database/listener logs or windows event logs for auditing purposes?
If you have database auditing turned on, is it logging to the file system?
>>where you have had to restore other files, just to put it into some context.
It depends on what all you are backing up with RMAN. Are you capturing the spfile?
I cannot remember the recoveries I've had to do over the years so I'm afraid I don't have any real-world 'gotchas' you need to focus on.
Hopefully some additional Experts on the site can share some.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
The concerns the admin is raising is that the server is still a physical server, running windows 2008 64-bit. And they dont have a spare server of the same type to test restores on. Whats your views on this? Is there any workaround? Do you need an exact system to test restores on?
OMG yes there's a workaround, known as "fail".
Sorry pma, but if your client has any clue about the cost of an unscheduled outage -- let alone a prolonged one -- the acquisition of a test bed is a no-brainer. IMHO of course.........
Sorry pma, but if your client has any clue about the cost of an unscheduled outage -- let alone a prolonged one -- the acquisition of a test bed is a no-brainer. IMHO of course.........
ASKER
Ok but in the days of physical servers, if you have 200 physicals running a multitude of different OS releases, did that mean you also needed 200 test physicals just for testing backup restores worked?
I feel your pain :) but that point begs the question: what is the alternative cost, in dollars and in customer goodwill, when the hard drive gives out on server #147? Oh, and the one admin who remembers how to set this server is out on medical leave -- and the "tricks" are only in his or her memory..... A thousand a day? Seems cheap. A thousand a minute? A half-day server build from scratch, under pressure, is going to impact someone's career track.
A rational case could be made that if one scratch-builds the host, why not scratch-build the tables, views, and packages as well -- just have a clerk type in the data row by row. What does it matter if it's slightly off?
It reminds me of the kid who sneaks some of the parents' booze, and then tries to cover up by adding water to the bottle. It may look the same at first glance, but......
Fact: A scratch build introduces the risk of undocumented, undetected change.
A rational case could be made that if one scratch-builds the host, why not scratch-build the tables, views, and packages as well -- just have a clerk type in the data row by row. What does it matter if it's slightly off?
It reminds me of the kid who sneaks some of the parents' booze, and then tries to cover up by adding water to the bottle. It may look the same at first glance, but......
Fact: A scratch build introduces the risk of undocumented, undetected change.
>>Do you need an exact system to test restores on?
Not 'exact' but representative.
>>did that mean you also needed 200 test physicals just for testing backup restores worked?
Did you not ever test things before you put them into production? You just grabbed the new version of, say Oracle, and installed it directly in production without any testing?
You should already have representative test hardware that mimics production. That is what you schedule time on for recovery testing.
>>Ok but in the days of physical servers,
You are aware of Oracle's official support stance on VMWare? If not, you should be...
Support Position for Oracle Products Running on VMWare Virtualized Environments [ID 249212.1]
Not 'exact' but representative.
>>did that mean you also needed 200 test physicals just for testing backup restores worked?
Did you not ever test things before you put them into production? You just grabbed the new version of, say Oracle, and installed it directly in production without any testing?
You should already have representative test hardware that mimics production. That is what you schedule time on for recovery testing.
>>Ok but in the days of physical servers,
You are aware of Oracle's official support stance on VMWare? If not, you should be...
Support Position for Oracle Products Running on VMWare Virtualized Environments [ID 249212.1]
ASKER