none
Backups and SCR RRS feed

  • Question

  • Hi

    Running Exchange 2007 SP2. We have one Active/Passive SCC cluster (Exch1) which has an SCR target (SCR1).

    Backups are running on Exch1 and apparently finishing ok, but the logs are not being purged for SG1. I checked SCR and the copystatus for SG1 is Failed. I understand that logs will not be purged if SCR copy is unhealthy.

    So, what's the solution:

    1. Reseed the copy and run a backup once that's complete
    2. Reseed the copy and the backed up SG1 logs will be purged automatically

    Bit of a chicken and egg scenario, what needs to be working for these logs to purge. This is made even more confusing by the fact that we had to manually move some older logs after the backup had completed since the SG was running out of space
    Monday, June 13, 2011 7:15 PM

Answers

  • Its not really chicken and egg, because you have two things going on.

    1. The backups.

    2. The replication.

    The fact that both have to complete successfully to allow the logs to flush is all that is required.

    Therefore you would usually simply reseed the database and wait for it to complete successfully. Then do a backup on the live server in the usual way. The logs will be flushed.

    If you had to move logs then you may have caused a problem with the backup and the log flushing. Moving the logs upsets Exchange. If the logs aren't flushing but you need space, compress them instead (compress at the file level, not the directory level as you shouldn't compress the live log file).

    Therefore what I would so in that scenario is stop the replication completely. Do a regular backup and confirm the logs flush. If they do not, then follow the procedure for manual deletion of the logs which is documented on Technet and/or MSKB.

    Once the logs are flushing correctly, reseed the database.

    Don't try and do too many things at once as you will simply cause problems.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.
    • Proposed as answer by Jeff Ren Wednesday, June 15, 2011 3:24 AM
    • Marked as answer by Jeff Ren Thursday, June 30, 2011 6:39 AM
    Monday, June 13, 2011 8:00 PM

All replies

  • Its not really chicken and egg, because you have two things going on.

    1. The backups.

    2. The replication.

    The fact that both have to complete successfully to allow the logs to flush is all that is required.

    Therefore you would usually simply reseed the database and wait for it to complete successfully. Then do a backup on the live server in the usual way. The logs will be flushed.

    If you had to move logs then you may have caused a problem with the backup and the log flushing. Moving the logs upsets Exchange. If the logs aren't flushing but you need space, compress them instead (compress at the file level, not the directory level as you shouldn't compress the live log file).

    Therefore what I would so in that scenario is stop the replication completely. Do a regular backup and confirm the logs flush. If they do not, then follow the procedure for manual deletion of the logs which is documented on Technet and/or MSKB.

    Once the logs are flushing correctly, reseed the database.

    Don't try and do too many things at once as you will simply cause problems.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.
    • Proposed as answer by Jeff Ren Wednesday, June 15, 2011 3:24 AM
    • Marked as answer by Jeff Ren Thursday, June 30, 2011 6:39 AM
    Monday, June 13, 2011 8:00 PM
  • Hello Simon

    So looks like I have messed up! Would you agree this is the correct solution as per your post?

    i. For SG1, stop SCR replication

    Disable-StorageGroupCopy -Identity <NameofStorageGroup> -StandbyMachine <NameofSCRTargetMachine>

    ii. Run a full backup (this should purge the logs)

    iii. Delete all files at the SG1 SCR target location

    iv. Re-enable SCR copy

    Enable-StorageGroupCopy -Identity <NameofStorageGroup> -StandbyMachine <NameofSCRTargetMachine>
    Monday, June 13, 2011 8:07 PM
  • Hi Pancamo,

    Sembee's advice is good.

    any updates for your issue?

    Thanks,

    Jeff Ren


    如果您对我们的论坛在线支持服务有任何的意见或建议,请通过邮件告诉我们。
    Description: Description: TechNet 论坛好帮手立刻免费下载  TechNet 论坛好帮手

    Wednesday, June 15, 2011 3:27 AM
  • Yes, could someone just confirm these steps are correct?

    i. For SG1, stop SCR replication

    Disable-StorageGroupCopy -Identity <NameofStorageGroup> -StandbyMachine <NameofSCRTargetMachine>

    ii. Run a full backup (this should purge the logs)

    iii. Delete all files at the SG1 SCR target location

    iv. Re-enable SCR copy

    Enable-StorageGroupCopy -Identity <NameofStorageGroup> -StandbyMachine <NameofSCRTargetMachine>
    Wednesday, June 15, 2011 6:57 PM
  • Yes, could someone just confirm these steps are correct?

    i. For SG1, stop SCR replication

    Disable-StorageGroupCopy -Identity <NameofStorageGroup> -StandbyMachine <NameofSCRTargetMachine>

    ii. Run a full backup (this should purge the logs)

    iii. Delete all files at the SG1 SCR target location

    iv. Re-enable SCR copy

    Enable-StorageGroupCopy -Identity <NameofStorageGroup> -StandbyMachine <NameofSCRTargetMachine>


    Yes, that looks correct.
    I am not getting alerts, so didn't know there were further posts.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.
    Wednesday, June 15, 2011 9:08 PM