Skip to main content
Question

File Share when database cloning


Forum|alt.badge.img+9

Hi,

What happens to File Share when we database clone for example a PROD DB to UAT DB while all the documents are in File Share.

I've understood it's a separate file share for each environment in managed cloud.

 

That is, is it taken into account in managed cloud procedures (and what to do in on-prem in that case) or do we find ourselves in a situation where none of the files can be found in UAT as all the file pointers are pointing to PROD File Share which UAT cannot access?

If so, any tips on how to get the File Share copied as well and all the pointers updated? 

Mathias Dahl
Superhero (Employee)
Forum|alt.badge.img+32

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.


Forum|alt.badge.img+9
  • Sidekick (Employee)
  • May 17, 2024

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.


Mathias Dahl
Superhero (Employee)
Forum|alt.badge.img+32

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.
 


Forum|alt.badge.img+9
  • Sidekick (Employee)
  • May 17, 2024

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.


Mathias Dahl
Superhero (Employee)
Forum|alt.badge.img+32

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.

 


Mathias Dahl
Superhero (Employee)
Forum|alt.badge.img+32

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?

 


Forum|alt.badge.img+9
  • Sidekick (Employee)
  • May 17, 2024
Mathias Dahl wrote:

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.


Mathias Dahl
Superhero (Employee)
Forum|alt.badge.img+32

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.
 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings