none
Migrating disks has completed but with 30+ errors RRS feed

  • Question

  • I used MigrateDatasourceDataFromDPM.ps1 to migrate a small disk to a larger one, I let it run overnight and here is the result:

    1. All data source on the old disk are gone, except an inactive one.  I manually remove it from Protection groups. 

    2. There are 30+ errors, with code 31221, 31224, and 355:

    **********************************
    You cannot migrate a replica that is not in a valid state. (ID: 31221)

    xxxx has recently been migrated. You cannot migrate GAMMA\msdb again until the recovery points on the previous replica volume a re available. (ID: 31224)

    Disk 1 cannot be removed from the storage pool because it contains storage pool volumes. (ID: 355)

    **********************************

    My question here -- when can I physically remove the old disk? How do I know the Recovery Points Volumes on it are all expired?  Will the "Unallocated space" grow by day, and I remove it when the size is close to the full size of disk ?

    Tuesday, June 18, 2013 4:04 PM

Answers

  • Hi Achen2002,

    <snip>
      I understand it takes time for recovery point volume to expire and be deleted, but after more than 48 hours, unallocated space on the migrated disk did not decrease [at all], and the number of volume did not change, either.  I counted 53 before starting the migration, and it is 53 two days after. 
    >snip<

    As recovery points expire on the old recovery point volumes, free space will increase on the recovery point volume, not the physical disk. No volumes will be deleted until all the recovery points expire on those migrated disks based on retention period.  

    If you had a retention period of 30 days, then you will need to wait for 31 days before the volumes are deleted on the old disks.  However, lets says for two days you did not get new recovery points made for a data source, then you will need to wait two additional days.  Retention range is based on the number of days that have recovery points, not calendar days.   You can make a recovery point status report to see if you missed any recovery points since migration to help you calculate when the old recovery points will expire.  It's first in first out FIFO. 


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, June 29, 2013 6:18 PM
    Moderator

All replies

  • You can remove the old the disk when all recoverypoint-volumes has been deleted, the usage will decrease and in Disk manager you'll see zero volumes. You can expect the old disk to be empty when you've past your longest retention-period on that dpm (plus one day since the pruneshadowcopies runs every night at 00:00). You can also run that script manually. Its located in the Bin\ directory together with the migrationscript... As describd here you can also lower the retentionperiod if you want the prunescriptscript to remove the old recoverypoints sooner.


    Ivarson

    Tuesday, June 18, 2013 9:47 PM
  • After all, all "Protected data sources" got removed from the old disk and created in the new disk.  I understand it takes time for recovery point volume to expire and be deleted, but after more than 48 hours, unallocated space on the migrated disk did not decrease [at all], and the number of volume did not change, either.  I counted 53 before starting the migration, and it is 53 two days after. 

    Could the errors that I mentioned above caused the "phasing out" of old disk not working properly ? It's OK for us to wait but I really wish I could actually see DPM doing some actions such as unallocating volumes which data has expired. 

    Is there any way to check status of the disk which was the source in a migration task ?

    Thursday, June 20, 2013 4:58 PM
  • Have you done a diskmigration before as it stated?

    If so, Mike Jacquet answered a thread here somewhere where he provided a stored procedure to fix those scenarios..

    What retentiontime do you have?

    Im having issues with stalled recoverypoints too, having Microsoft trying to help me out.

    You can always pick a time where you havent many scheduled jobs, and run the pruneshadowcopies-script manually as Admin and Verbose mode. If there are errors in the process of removing RP's, theyre probably easier to find there then in the messy Temp\ dir where the logfiles are.

    start-transcript -Path C:\prune.txt

    .\pruneshadowcopies2010.ps1 #Asuming your in the Bin folder of your dpminstallation...

    stop-transcript 


    Ivarson

    Friday, June 21, 2013 10:21 PM
  • Hi Achen2002,

    <snip>
      I understand it takes time for recovery point volume to expire and be deleted, but after more than 48 hours, unallocated space on the migrated disk did not decrease [at all], and the number of volume did not change, either.  I counted 53 before starting the migration, and it is 53 two days after. 
    >snip<

    As recovery points expire on the old recovery point volumes, free space will increase on the recovery point volume, not the physical disk. No volumes will be deleted until all the recovery points expire on those migrated disks based on retention period.  

    If you had a retention period of 30 days, then you will need to wait for 31 days before the volumes are deleted on the old disks.  However, lets says for two days you did not get new recovery points made for a data source, then you will need to wait two additional days.  Retention range is based on the number of days that have recovery points, not calendar days.   You can make a recovery point status report to see if you missed any recovery points since migration to help you calculate when the old recovery points will expire.  It's first in first out FIFO. 


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, June 29, 2013 6:18 PM
    Moderator
  • Thank you Mike, I have some more info to share here. 

    After proceeding with two more migration tasks (without errors !), I realized there was indeed something wrong in the first one that I did as described above.   The most important thing is -- if the migration task was completed properly without error, the original disk should disappear from DPM console - Management - Disks, in my 1st task it did not.  And that made this disk still being used as storage target when I created new recovery jobs.

    I had to run MigrateDatasourceDataFromDPM.ps1 on it again, to "de-commission" it successfully. Now I care less about "Unallocated space" of the old disks, because they have been removed from DPM console and not accessible anymore.  I will just mark my calendar and physically remove the HDD's after 30 days. 

    Wednesday, July 3, 2013 5:23 PM