Hi,

I'll assume you meant File Storage above.

In Remote deployment you need to take care of copying any files that are not stored in the database, if you clone it. Take extra care to use different shares for Prod and Test, etc. such that testing in Test does not overwrite files in Prod.

In Cloud deployment, I don't think File Storage is cloned at all today, and different storage account are used in Azure.

Thanks. Yes, File Storage.

So how to achieve same functionality when cloning today also in managed cloud?

It would be a large task to migrate all documents every time a database copy is made.

I'm still worried about file pointers. If PROD is cloned to UAT will all pointers still point to PROD and as the shares are separate the new UAT won't be able to access any files.

It would be a large task to migrate all documents every time a database copy is made.

Why would you want to do that?

I'm still worried about file pointers. If PROD is cloned to UAT will all pointers still point to PROD and as the shares are separate the new UAT won't be able to access any files.

There are no shares used in File Storage in Cloud deployment (managed cloud). There are no pointers in Docman nor the File Storage file reference tables pointing to the Azure Storage account, so no pointers will be cloned. You might think the problem is similar to the one we have with FTP and Shared repositories in Docman, but it's not.

In Remote deployment on the other hand, you need to be careful to configure File Storage in UAT/DEV/CFG to point to another network share than PROD. Once that's done, you should be able to clone the database without risking overwriting files.
 

I’m probably not seeing the whole picture as I’ve only been involved with database clones containing the files in the database - hence everything is simply cloned and there’s nothing to worry about.

So are you saying cloning PROD to UAT with File Storage enabled would ‘just work’ in managed cloud, with copies of all the PROD documents being accessible from the new UAT without any action (just like if they were included in the database).
I don’t see how that works if repositories are separate as said by Cloud Support. But like said, I don’t seem to have the whole picture. It would be good for this to be spelled out in some KBA so that everyone is on the same page here. :)

You wrote earlier “ I don't think File Storage is cloned at all today, and different storage account are used in Azure.” so I’m a bit confused here - does everything work automatically or not, and what do we do in that case.

So are you saying cloning PROD to UAT with File Storage enabled would ‘just work’ in managed cloud, with copies of all the PROD documents being accessible from the new UAT without any action (just like if they were included in the database).

Not at all.

No cloning of the files stored in Azure Storage will be done unless effort is put into that. But there is no risk of overwriting files in PROD when testing in any of the other environments. That is my message.

I'm invited to a meeting next week on how to handle cloning of File Storage files.

Reminder:

It would be a large task to migrate all documents every time a database copy is made.

Why would you want to do that?

This was just me listing ramifications of File Storage instead of database when cloning.
I do not want to migrate all documents every time a database copy is made, but I’m not seeing a better option yet.

Maybe you will have the information after the meeting, please share it here.

Thanks! I think the idea is to decide on one or a few options to define the scope of what should be cloned (based on document class, based on the business object the document is connected to, etc.).

In my view though, in most cases the number of documents that are needed to test in UAT/DEV etc. should be so few that they can be uploaded manually when needed.