Snapshot XP with Oracle ASM disk volumes...issues

[Thomas Callahan]

I'm working on creating snapshots using our XP24000 storage array. I will be snapshotting Oracle ASM volumes. The operating system is RHEL Linux 5.2 64-bit.

Each volume is a 25GB disk, with a single partition. The data stored within is managed by Oracle.

I'm creating the snapshots the usual way, onto a V-Vol with a 2TB pool behind it. The snapshots split correctly, and I can see the data change percentage changing, and I can see the pool space being used.

In my test, I am dd'ing the disk after the snapshot has been taken, (dd if=/dev/urandom of=/dev/sda bs=512 count=20000)

When I go to restore the ASM volume, I would expect to see the partition table recreated by the restore. However, that is not occurring. It's almost like the restore is just not working.

I am positive the snapshot configuration on the XP24000 is correct, and the raid manage commands I am using are correct, as I have performed the same test with an EXT3 filesystem, and I can see the data come back. It just seems that a snapshot restore is not restoring the partition table of the disk.

Does anyone have any experience or tips with this?

Thanks,
Tom Callahan

[Ivan Ferreira]

In fact, that should work. Can you give a little more details about your tests, with error messages and the way you try to access your ASM information before/after restore/resync.

[Thomas Callahan]

I'm working with an HP tech on this as well, but first thoughts are that because I'm changing the partition table, using a DD, that this may qualify as P-Vol corruption, whereby the snapshot is invalid.

Slightly ridiculous if you ask me, but we'll see I guess.

Our ASM disks have only one partition on them, created with a standard fdisk command. After this is done, I snapshot the volume. Then I dd the disk, effectively wiping out the partition table. Then a "pairresync -restore && pairevtwait" is done, and once status has gone back to pair, I check the disk again. But there is still no partition table.

[Nigel Poulton · Accepted solution]

Long long long shot here (Im no expert on how RHEL and associated file system works......).

Is it possible that the changes made to the partition table have not been flushed to disk (and hence to the COW S-VOL).

Ive worked with COW snapshots on XPs a lot in Windows environments and crazy things like this can happen if you dont take snapshots via the Windows API (VSS) as occasionally the changes are held in local OS cache on the server. Snapping via the API ensures that all filesystem changes etc are flushed to disk to ensure a consistent snap. Slightly different I know, because you are dd'ing the disk after tha snap, but may be the principle is the same - the changes might not have been flushed to the P-VOL and therefore the previous data not been preserved on the COW S-VOL........

May be try a sync or whatever the command is before performing the pairresync.

Just a thought

??

[Thomas Callahan]

I never even thought about the cache on the OS. I repeated my steps again, with a sync inserted at appropriate times, and low and behold, it works.

Thanks a ton for the insight!!! Appreciated.

[Thomas Callahan]

Closed