2012-04-09 08:38 AM
Due to an manual error during snap-mirror update, one of the volume in an aggregate got over written with old data. As there is an recent aggregate snapshot existing, we are trying to recover the same but the aggregate on which the original volume exists has other multiple volumes, which are in production, hence not in a position to restore the aggregate snapshot. In documentation it was read that, we can copy the aggregate, along with snapshots, to any free space either in same or other filer and we do have another filer with almost same free space. For the same aggr copy with the below option is tried out for copying the aggregate, but this option is not working out, and fails with below errors. Even though there are certain workarounds for such errors mentioned in some of the KB's, it was of no use. Looking for any help on the same or suggest any alternate option for recovery. Thanks in advance.
jinga> aggr copy start -S infrasec:aggr2 infradr:aggr6
This can be a long-running operation. Use Control - C (^C) to interrupt.
Copy Aggregate: aggr2 on machine infrasec to Aggregate: aggr6
AGGRCOPY: Read Socket received EOF.
AGGRCOPY: Cannot Init Input, aborting
2012-04-09 08:51 AM
It may not be able to create a new snapshot for the aggr... have you tried -s to specify the specific snapshot you want (and hopefully get it copied before it autodeletes)... maybe turn off the scheduler (snap sched -A or aggr options) until you get the copy done too.
2012-04-09 10:50 AM
I really wish we had a "snap restore -t file -A" capability...a volume is file level in that sense but doesn't work... then in place volume recovery would work. We have used aggr copy to copy out then back but the single object restore of a volume in an aggr (like a file in a volume) would be really nice to have.
2012-04-10 01:15 AM
...a volume is file level in that sense
Nice one We had a discussion a while ago, whether or not an aggregate could be mounted: