Hello Zoltan,
sorry, I misread this as damaged dedup pools, so next try:
--
Michael Prix
On 5/11/21 10:40 PM, Zoltan Forray wrote:
Your response does have relatable instructions but I have questions:
1.) Identify the damaged, or lost, containers ("volumes" of the
dedup pool) and mark them
Your response does have relatable instructions but I have questions:
>>>1.) Identify the damaged, or lost, containers ("volumes" of the
dedup pool) and mark them damaged or destroyed. Use "audit container"
for this. In your case, as you might have lost some filespaces
completely, "update stgpooldi
Thanks for the reply. I should have clarified these are regular FILE disk
pools, not Containers..
On Tue, May 11, 2021 at 4:21 PM Michael Prix wrote:
> Hello Zoltan,
>
> recovering deduped pools after a desaster, even a partial one, has some
> drawbacks.
> Deduplication information is bound
Hello Zoltan,
recovering deduped pools after a desaster, even a partial one, has some
drawbacks.
Deduplication information is bound to the storagepool, not the
TSM-instance, so you have to restore the lost data to the same
storagepool. There is no "restore volume", as there are no volumes as
7.1.7.400 Linux server
We had a multi-disk failure event occur in one of our PowerVaults so an
array is damaged along with lots of volumes.
Tried to do a "restore stgpool" or "restore volume" to other stgpools but
it says you can't do that for deduped pools/volumes.
We have been running movedata
