Backup Copy Job problem

[nholman]

Hi
The last year we have been sending our backups to a Dr4100 Dedupe Appliance and was our only repository.
This as you know is no good for instant vm recovery or virtual labs due the deuplication.

We now have a DAS 12GBs Array attached to the backup server and would like the backups to go here first a retained for a week but have backup copy jobs to go to our DR4100 for longer retention. I want the backup copy jobs to seed from our new backup array to our Dedupe appliance as all our backups for the past 30 days are there and do not want to start again really.
When i try to acheive this i get this error:

No backup is attached. Cannot map a backup

Can anyone advise what im doing wrong please ? The 30 days of exsiting backups cant be useless surely?

[foggy]

Nick, the fact is that backup copy job cannot be mapped to the backup chain is produced by the regular backup job and contains increments (it can be mapped to the single active full backup only). There's a workaround for that, however, I suppose making a new full cycle in your case is easier, as you're not backing up offsite, right?

[nholman]

Hi foggy

That's right. The SAS array and dedupe device are both on the same site. Have looked at the thread you mentioned and can't really figure out which option is best for me

[foggy]

I was talking about procedure described in the particular post I was referring to - creating a new full from backups already available on the dedupe appliance that you could then map the backup copy job to. However having everything on a LAN you can just perform backup copy directly from the SAS array.

[nholman]

hi foggy
are you suggesting i not try anything fancy and just start a new backup copy job,(link it to the new locala SAS array job thats pointing to the local repo) and let it seed to the dedupe?

[veremin]

I believe that is exactly what Foggy's suggested. As everything is located on a LAN, you can simply start a direct backup copy job as is without dealing with seeding first. Thanks.

[nholman]

Hi

Thanks for clarifiying.That what i thought...only issue with is that we are low n disk space on the Target Dedupe device as this was being used as our primary repository and therefore we have between 14 to 30 days of backups on there depedning on the specific jobs we have. What can i do with these ?
I dont think there is enough space for copy jobs of all our jobs. we are talking 20TB of data that we have on there, and thats being de-duplicated!

[veremin]

Backup copy job doesn't t copy backup chain as a whole, but rather synthetically creates required restore points in "target" location from VM data in source backup repositories. So, it means that a newly created backup copy job won't re-create the whole backup chain. Instead, it will synthetically create one restore point containing the latest state of the chosen source. Thanks.

[nholman]

OK.

Im abit cnfused about what to do now to move forward? I dont want to lsoe the historic backups we have.

[foggy]

Let them reside on the storage until the new backup copy job reaches the required number of restore points.