Solved

Azure Immutable Blob Library - WORM applied without warning through workflow

  • 16 March 2021
  • 8 replies
  • 686 views

Badge +5

Hi,

I have another trouble with the Azure immutable blob library. I started a recommended workflow “ Enable WORM on Cloud Storage”. Because we have not the “IAM VM Role Assignment” authentication method(we have Access key), the workflow was not completed. But it set “WORM” option on the cloud copy without a warning. Now there are some “Index server backups” which will not expire. They cannot be deleted (WORM copy) and block a whole baseline in the cloud. Maybe I have to open a support ticket for it ? Because I had already similar problems with these Index server backups, maybe it would be better to save these backups in another “no WORM” storage policy ? (I guess restore of data could be possible without these index backups too - with some performance penalties necessary for rebuild of indexes (?))

This is only a test storage policy with one client VM, but the customer plans to place  about 150TB to cloud. So “locked” data in the cloud could be costly.

FYI see content of all relevant SP copies in the attachment.

Thanks

Jiri.

icon

Best answer by JNIZ 1 April 2021, 14:47

View original

8 replies

Userlevel 7
Badge +23

@JNIZ , I split this thread off to track the solution separately.

It sounds like the workflow didn’t complete 100%, but some of the items within DID complete.

I generally would try and troubleshoot here, but in this case, I would suggest opening a ticket with support.  We can track the solution to document here afterwards.

Badge +5

@Mike Struening 

Hello,

yes some things were done and the workflow didn’t finish. Nevertheless now is the situation with WORM option set and I have a deadlock, which I am not able to solve. I see only solution:

  • ask customer support to unlock the WORM copy (or is any other way ?), then delete not-expired jobs and release Azure blob storage
  • why don’t the Index server backups expire ? They should start every day at 1:00 PM. Some days there are backups some days not (or with size of 0), which are not taken into account.
Userlevel 7
Badge +23

@JNIZ , to me there are 2 issues:

  1. How did the workflow ‘fail’ but ‘work’ in some regards?  Might be intentional, but also might be something that can be modified to allow only all or nothing.
  2. changing WORM is potentially possible but only through development.

Open a case through customer Support and let us know what they find.

Badge +5

@Mike Struening 

Thanks for your support, I will open a case related to the WORM/Immutable Azure storage.

Jiri.

Userlevel 7
Badge +23

@JNIZ , can you share the case number with me?  I want to track the solution for the thread.

Badge +5

@Mike Struening 

I opened a case # 210319-466 . We have there a problem with expiration of Index Server jobs in the test cycle. So I asked to reset the WORM option on cloud copy. I have no answer yet.

Regarding workflows, descriptions in docu for V11.21 and V11.23 are different (seal/retention/Azure time retention). So I am a little confused, what the workflow (there is only one version in store) really does. We have currently V11.20.36 (can be updated if required).

Thanks

Jiri.

Badge +5

@Mike Struening 

Hi, there is really a problem with expiration of Index backup jobs on WORM copy. Should be solved in the near future, see the case. So I asked to reset the WORM setting.

Regarding different seal/retention/Azure time retentions, we will test the cycles in production. Every experiences are welcome.

Thanks

Jiri.

Userlevel 7
Badge +23

Appreciate the response, @JNIZ !! Adding the CMR number for this issue: 313704.

Regarding other’s experiences, it might be best to start another thread under Best Practices (as a Conversation) for ideas on Azure.  Normally, I’d split this off for you, but the newest reply has the answer!

Reply