09-17-2013 08:26 AM
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
Solved! Go to Solution.
09-17-2013 10:31 PM
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
09-17-2013 10:31 PM
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
09-18-2013 12:12 AM
@phk: I probably forgot to mention that it's a remote recovery, and according to Colin's comment that should work.
09-18-2013 12:20 AM
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.
09-18-2013 02:00 AM
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...