2011-03-08 08:54 AM
On the top of page 373 of the SMSQL 5.1 IAG, it says:
"It is not recommend to change the SnapManager database configuration when a new database is added to the server. For example, if you have only one database in a LUN or VMDK and you add the new database to the same LUN or VMDK, the SnapManager configuration for the original database will change from nonshare configuration to share configuration. The old backups for the original database might be deleted, and an up-to-minute restore for old backup might not be possible."
This is a bit scary...why would old backups be deleted? Thanks for any ideas,
2011-03-08 09:20 AM
I *think* this is because of the fact that Snapinfo LUN holds all the logs for the up to the minute restore capability (this is what I actually learned recently on communities ). So the risk is Snapinfo content may get wiped off, not the actual snapshots.
2011-03-08 09:27 AM
Because of poor coding!
No, seriously - I have no idea. This was the only thing remotely making sense in connection to what you quoted, hence I brought this.
2011-03-15 06:37 PM
This behavior was changed in SMSQL 5.1, where the old backups would not be deleted when configuration was changed from non-sharing to sharing, or from sharing to non-sharing. Although the older backups were retained, the restorability of those backups would be limited, for example, up-to-minute restore might not be possible from SMSQL, since the configuration was changed, SMSQL would not be able to get right transaction log backups for the UTM restore.
2011-03-15 07:19 PM
Thanks Qing. So, is this a bug in the SMSQL 5.1 documentation that needs to be fixed? If so, I will file a documentation bug to request that the statement around backups possibly being deleted when changing from a non-shared to a shared config should be removed or modified. Thanks,