This post is more than 5 years old
6 Posts
0
951
a question about TimeFinder cloning an NTFS volume
Hello.
I have an issue with corrupt NTFS filesystem after copying the volume using timefinder clone. Now to be honest, I haven't really been doing this with windows disks (only AIX, Linux, ESX and Solaris). This is what happends: I run a timefinder clone activate -consistent against a production volume, and try to mount the copy on another identical host. After discovering the devices through add new HW wizard, I try to mount the filesystems, but windows says the filesystems on the drives need scandisk, so I run that first. Unfortunately scandisk always finds corrupt files, which then become useless (it doesn't seem to be able to fix them). Obviously the database residing on those disks cannot be recovered either. What do I need to do with windows on the production or copy side to get rid of the problem?
Obviously, shutting down production to clone copy it kinda defeats the reason for running clone in the firt place. I can copy it using plain copy, or scp, or whatever if I need downtime. Why doesn't the TimeFinder clone work with windows the same way it does with UNIX environments?
Thanks in advance for any help anyone might provide.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 25th, 2010 06:00
Jurica
6 Posts
0
February 25th, 2010 07:00
Well, yes it is MS SQL database. Until now I've only worked with oracle, informix and sybase. So MS SQL is actually unrecoverable if the server crashes because of, say, power outage?
That means even SRDF/S can't really protect those databases in case of a serious disaster of a site.
I gues that answers my question.
Thank you.
RRR
2 Intern
2 Intern
•
5.7K Posts
1
February 25th, 2010 07:00
Yes, you're correct. I was just thinking out loud....
I must say that I've been using SRDF/S, SRDF/A and Mirrorview/S and /A for years and I've never heard any DBA complain about this. And I never thought about it to test whether or not a database could be recovered after what you described.
Jurica
6 Posts
0
February 25th, 2010 07:00
Yes, I know they reached the other side, but as it turns out, in case of MS SQL that doesn't really matter, does it?
Because with crash consistent clone you also get the same thing: all I/O's reached the "other" (copy) side, and you still get a trashed DB
RRR
2 Intern
2 Intern
•
5.7K Posts
0
February 25th, 2010 07:00
Dynamox is correct (as always): without any integration packages, you will indeed get crash consistent LUN's. Hoewever, since you are using SRDF/S, all I/O's have reached the other site in order, so you shouldn't have to worry about databases being ahead of the logs or anything. With SRDF/A you need to put all LUN's in consistency groups to be able to get to a crash consistent state.
Jurica
6 Posts
0
February 25th, 2010 08:00
Nope. Sorry to disappoint. It won't come up at all. I'm not even sure it's a db problem. You see, windows (OS) says the disks are bad and need scandisk. Not DB. And after scandisk fails to restore some files, the database can't recover.
I've also been working with srdf/s and timefinder clone, and a few other vendors solutions (ShadowImage by hitachi) for years now, and as long as we're takling UNIX or MF, there's no problem. Even ESX (which is also kinda hacked linux) doesn't complain. But win+MS SQL just doesn't seem to work.
Jurica
6 Posts
0
February 25th, 2010 08:00
Nope. No need. Worst case scenario, it will ask you for the most recent archive log, but if you also clone those, you can just do
- startup mount;
- recover database;
- open database;
That's it.
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 25th, 2010 08:00
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 25th, 2010 08:00
AranH1
2.2K Posts
0
February 25th, 2010 09:00
MS SQL will recover from a crash consistent copy of the DB just like any other DB out there. Common, it runs on Windows. You don't think there has been a Windows SQL server that crashed and had to come back up on a crash consistent database?
As you pointed out though you are not even able to surface the LUN and mount the file system. That is the problem. Not sure why that is happening, I have taken clones and snaps of NTFS volumes hosting SQL DBs and have always been able to recover the DB.
Jurica
6 Posts
0
February 25th, 2010 23:00
I think you're right. That shoudn't happend. I'll open a SR and see what support has to say about it. I just hope they dont tell me something along the lines of: "well, you really need that integration package, because we can't help you if you don't"