asked on
How to properly seed a database using SCR
I need to seed an existing database for use with SCR. The database is too large to copy over my WAN to a remote site. I am not clear on the proper powershell command to use. I know there is a -seedingpostponed and -Truncatelagtime command but I am not clear what they do. The problem as I see it is that it would take a couple of days to get the .mdb file to my disaster recovery site and if we do a backup in between the time I dismount and copy the database to media to transport it to the disaster recovery site, and it actually gets copied to the SCR server, the logs will get flushed and they won't be available to play back into the database. What are you supposed to do? Not do backups? I can't find a good article that explains this clearly.Everything I have read says use the Update-storageGroupCopy command but that will pull the database over which I cannot do over a WAN. There has to be a way to do this.
Exchange
Last Comment
osiexchange
ASKER
Thanks but that really doesn't answer my question. I know all about that. What I would like to know is what happens to the log files during transit of the .mdb file to the SCR server. As I said, it could take up to two days to get this files in place. We do backups every day. If the log files get flushed during the backup then they won't be there to play back on the SCR server. Thats why I said, do you not do backups while the file was in transit. I found plenty of articles say what you just said, but they never address the issue of time and preserving the log files on the source server while the .mdb file is being moved to the SCR server. Consider this senario. I enable Storage Group copy using the -seedingpostponed command. This automatically suspends the Storage Group copy. I dismount the store and copy the .mdb file to a USB drive and remount the store. During transit of the .mdb file to the SCR server, we do an incremental backup and flush all the logs that were generated since I remounted the store on the source. Now these logs are not available to copy to the SCR server so the .mdb file is useless.
Hello osiexchange,
The log files are not purged if you have the SCR or any type of replication is been enabled untill it is been replicated to the other node.
Thanks,
x-sam
The log files are not purged if you have the SCR or any type of replication is been enabled untill it is been replicated to the other node.
Thanks,
x-sam
ASKER
So what you are saying is that if I enable the Storage Group copy to the SCR server but postpone the seeding using the -seedingpostponed switch, that if we run an incremental backup on that Storage Group, the log files will remain on the target. I am a little bit confused as to what you are saying.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
My tests tell me something different. If I enable storage group copy with the seedingpostponed switch,
after our backup runs, the logs files are flushed if I look in the log file directory. Unless the log files that are to be copied to the SCR server are stored somewhere else.
after our backup runs, the logs files are flushed if I look in the log file directory. Unless the log files that are to be copied to the SCR server are stored somewhere else.
Copy the flat file of the existing database after dismounting the stores.
Move this file to the other server manually.
Once this is done. Mount the original store and then resume the storage group copy.
This should help you much better.
Thanks,
x-sam