• We've had SnapManager in place now for several months as our primary backup solution and I can't say I'm overly thrilled with what we've witnessed. In large part because it's owned/configured/managed by a team of network engineers at another location so it's kind of a black box process for myself and our local engineer. As such, I'd like to run some things by people who know better than I as we put together a plan forward.

    1. Currently SnapManager creates a snapshot (separate data and log volumes) of our database server. That snapshot is mirrored to a standby server for DR purposes. That mirror is then cloned to another server for restore for consistency checks and internal reporting purposes. Frequently the clone step fails because the data and log volume snapshots are out of sync. If the clone snapshots can be out of sync can the same be true of the mirror? I'd hate to have to fall back on the DR copy to find it's out of sync.

    2. Removing (and adding) DBs without modifying SnapManager causes issues. We were told whenever we do this that SnapManager has to re-configured. Knowing that then it's not truly volume replication but file replication within a specific volume. Sound about right?

    3. Our previous backup policy was taking a full DB backup on the weekend and differentials/logs during the day/week. Since implementing SnapManager, and because I don't trust a process I'm not in control of, we've switched to a daily full backup because SnapManager updates the last backup date and thus invalidated the (native) full backup. Anybody got a workaround for this?

    Thanks in advance for any replies and if I'm way off base here please let me know. This is a technology I'm not overly familiar with, have limited if any control over and which was "strongly suggested" for us to implement.

    -Nate

    _____________________________________________________________________
    - Nate

    @nate_hughes