Seed drive consumption blocks replication for seeded machines?

I'm backing up 4 new machines(VMs).  and I have 4 existing.  I made the Seed drive for the 4 new machines(took days), drove to DR site, plugged in and I'm now consuming Seed drive.  BUT it looks like the replication job for the 4 new machines is waiting for Seed drive to finish consuming?? (existing 4 are replicating fine) it will take about 5 more days!  while I was creating the seed drive replication from 4 new worked perfectly.  is this behavior normal?  I fear that after 5 days of consumption there will be enough changed data (due to no replication) that something will get marked for New Base image.  that would defeat the whole purpose.

Parents
  • The consumption of a seed will block new data being written to that replicated machine. That's falls under the '2 hands in the cookie jar' you can't have 2 things writing to the same recovery point chain(s) at the same time. This is completely expected, working as 'designed' so to speak to protect data integrity. Now the other part of your question about the base image, there isn't a change threshold where it rebases, that isn't in the list of variables to rebase: support.quest.com/.../unexpected-base-images-created-in-rapid-recovery-6

    If the protected machine changes 76% your incremental is 76% the size of the disk. Also there isn't a date threshold for a new base either, you can go say 88 days without a backup and it'll do a incremental as long as none of those factors in that KB are met. 

  • thanks very much.  answered my question perfectly.  one last thing; in general "days" to consume a seed drive is normal (probably 8tb).   it's going into a not super fast storage setup, maybe that's why.

  • Sure thing. For whatever it's worth, its that same thing where if you were to do an archive of say 5 TB, so it'll take days. Now an archive isn't writing to the repo, so it does not block the backups from happening. However, the nightly rollups will kick in within 24 hours, and the archive will prevent that from running as it'll try to modify the RP chain. So even though it appears as though the Archive blocked the transfers, the moment you cancel the rollup, the backups begin again. Snake eating its tail, Archive blocks Rollup, Rollup blocks Transfer. 

    I'm assuming your seed was a USB drive. This is an AGE old question/concern with all data protect, RR included. I wish I had an answer however as a whole you'll probably never see USB 3 transfer speeds while you create and import archives/seeds. This is for a multitude of reasons (8k blocks, dedupe, compression) and yeah. Age old question of why doesn't it go fast enough for the seeds/archive - again, much like the various other product lines as well to be honest. 

Reply
  • Sure thing. For whatever it's worth, its that same thing where if you were to do an archive of say 5 TB, so it'll take days. Now an archive isn't writing to the repo, so it does not block the backups from happening. However, the nightly rollups will kick in within 24 hours, and the archive will prevent that from running as it'll try to modify the RP chain. So even though it appears as though the Archive blocked the transfers, the moment you cancel the rollup, the backups begin again. Snake eating its tail, Archive blocks Rollup, Rollup blocks Transfer. 

    I'm assuming your seed was a USB drive. This is an AGE old question/concern with all data protect, RR included. I wish I had an answer however as a whole you'll probably never see USB 3 transfer speeds while you create and import archives/seeds. This is for a multitude of reasons (8k blocks, dedupe, compression) and yeah. Age old question of why doesn't it go fast enough for the seeds/archive - again, much like the various other product lines as well to be honest. 

Children
No Data