cancel
Showing results for 
Search instead for 
Did you mean: 

SDR: Recovery shows Backup Sets, but then hangs in loop (3600 R2)

Hi folks,

the recovery work beautifully until the point where the actual recovery should start: Server and backups sets are visible and can be marked,

but when you start the recovery process, nothing more happens. The Appliance shows a recovery job for the temporary server, but then vxmon

(set to display only "third party debug output") shows an endless loop, it seems when trying to access the actual backup sets on the appliance's dedup storage.

Does anybody have an idea of the cause?

BTW: what other surprises does the 3600 R2 have in store in your experience?

Thanks in advance,

Bert

1 Solution

Accepted Solutions
Accepted Solution!

You cannot use SDR with

You cannot use SDR with dedup'ed data.  If you want to do SDR, you need to do a backup to ordinary disk or tape.  Duplicating your existing backup sets on your dedup folder will also not work.  See this comment by Colin Weaver.

https://www-secure.symantec.com/connect/forums/backup-exec-2012-sdr-local-usb-disk#comment-8568491

View solution in original post

4 Replies
Accepted Solution!

You cannot use SDR with

You cannot use SDR with dedup'ed data.  If you want to do SDR, you need to do a backup to ordinary disk or tape.  Duplicating your existing backup sets on your dedup folder will also not work.  See this comment by Colin Weaver.

https://www-secure.symantec.com/connect/forums/backup-exec-2012-sdr-local-usb-disk#comment-8568491

View solution in original post

@phk: I probably forgot to

@phk: I probably forgot to mention that it's a remote recovery, and according to Colin's comment that should work.

 

No.  When did he say that

No.  When did he say that dedup'ed backup set can be used to recover remote servers?  The document he quoted is very specific, SDR cannot use dedup'ed backup sets.

Quote Colin from above

Quote Colin from above link:

"I believe the first point is because the SDR disk does not run any Dedup services so can't do a local restore (but can do remote dedup restores) and the second point does mean that it has to be a scheduled/linked duplicate and not a manual one run after the fact."

Mind the "local"; I am attempting a remote restore, so that should work (and I see no earthly reason why BE should treat the restore job any differently than other restore jobs, at least as far as the storage is concerned...