Re: Restoring a level-1 backup at a later date?
The original poster discovered HDR cannot replicate blobspaces (IDS 9.30). Ben Thompson explained that blobspace data bypasses the logical log, which HDR ships, so changes are not replicated. The poster noted even 9.40 cannot, and that dbspace blobs would cost performance, and worried logical log backups would leave blob restores inconsistent. No solution given.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
To all those who suggested we use HDR for this; there was a small bell ringing at the back of my mind and eventually I worked out why. You CANNOT USE HDR TO REPLICATE BLOBSPACES!!!!!!!!!!!!!!! (At least in IDS9.30 anyway). Why oh why oh why the hell not? Malc (seething 'cos we'd more of less decided on this course of action.)
malc_p@btinternet.com wrote: > To all those who suggested we use HDR for this; there was a small bell > ringing at the back of my mind and eventually I worked out why. > You CANNOT USE HDR TO REPLICATE BLOBSPACES!!!!!!!!!!!!!!! (At least in > IDS9.30 anyway). > Why oh why oh why the hell not? Isn't it because using a blob space speeds things up by avoiding the logical log entirely? HDR works by sending the logical logs from the primary server to its secondary and therefore changes are not replicated. Ben.
Yup. Even if we were using 9.40 we couldn't replicate blobs in blobspaces. Oh yes we could put the blobs into standard dbspaces but then we'd have the concomitant reduction in performance (our blobs vary from 20Mb or so up to some in excess of 200Mb). All in all it makes a mockery of the term "HIGH AVAILABILITY" doesn't it?
As a further muse on this........ doesn't this mean that there's no point in our doing logical log backups during ordinary day-to-day processing because if we had a disaster scenario and restored a level-0 followed by logical log rollforward we'd lose any changes to our blobs so the restore would be inconsistent? Serious implications here for our in-house strategy.