Are you using onpremise, azure, or amazon for your hosting enviroment.  I guess lets first start there and then we can hammer out details :)

They are not using Azure, or AWS, they have there own didcated servers running an idividual instances of IIS with a SQL for each enviroment. 

A couple of ways to handle this.  DFS is one of them.  We have used this in the past for keeping insync with the different enviroments via blob storage that is.  Another client requested that we store the files in the database.  Now there is overhead with storing them in the db but once they are cached, you should be relatively happy with the load. 

Another option is to setup a one way MIRROR that will replicate to the other enviroments as well.  This is a very strict on the setup but once you have it, it will sync accross to the other enviroments listening. 

I am not sure there are any tools that will sync db(content) and assets all at once other than the mirror currently.  Hope this provides you with a little guidance and a starting point.
Here is the link if you would like to read up on it (https://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Deployment/Mirroring/Mirroring/)

Joshua

Thanks Joshua, I will check the documentation around mirroring.

So by default am I right in thinking that by defult episerver will save images that you have uploaded via the back office end up /App_Data/blobs ?

When you use the Export data feature in the Admin of Episerver does it it include these media files?

Do I need to copy the database from production to staging for example to make sure the media and db are in sync?

Hey Ayo,

That is correct.

So by default (out of the box), episerver has a node in the web.config called AppBasePath="App_Data" or some variable.  I have a tendency to change this outside the webroot since we source control our code and assets don't get sourced.  So by default, when an editor/user uploads a file via edit mode, it EPiServer will save the file in in the appbasepath+"/blobs".  So in the example above it will store it in  App_Data/blobs/.  Now with that said, you can set this base path to anwhere.  Sometime we use a network share depending on the clients requirements and setup.  Hope that helps on the upload path.

When you save the media, a contentreference is stored in the db to that file. This is where the database comes into play.  So, when you do an export/import, epsierver will only get the pages/media that are linked to the current items in your selection based on the checkbox in the export feature "Export files that the pages link to".  It will create a backup of the pages, folder, and media that the page has links too or links to that page.  Now, when you import, there is a checkbox that states "Update exisitng content items with Matching ID".  When you import this data, it will either 1. update the current item based on the id, if it doesn't exist, 2. it will proceed to create new content items for this and keep the softlinks in tact.

So in your case, you have 3 matching(somewhat) enviroments.  I would do the following without mirroring if it were me.  Since you do not have a shared location for your files to be stored and also, you more than likely use dev and integration for testing/content entry samples, you would restore the production database back to the 2 enviroments and then manually copy the app data / blobs folder from production back to the two integration and dev enviroments. 

So, to circumvent this manual copy of blobs, you can either store the files in a shared location that all three sites talk too, which i wouldn't recommend as if someone update the file in dev, it could possibly leak into prod somehow.  Or you can save your files in the db as binary data.(https://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2014/4/SQL-Blob-Provider-Store-your-blobs-in-the-database/) and that way, a back and restore of the database will take care of the files for you.  The alternative as stated above is to use mirroring and handle it that way.  There are pros and cons to the mentioned above but i will let you dictate what is best for your needs.  I hope this helps clarify blobs and how they are managed.

Joshua Folkerts

Thank you Joshua, this is what I was looking for a genreal overview of Episervers behaviour in regards to media. - I have got a better understanding now of how it all works.

However I just want to clarify a few things you just said.

1. When you do a Import/Export you say - "epsierver will only get the pages/media that are linked to the current items in your selection based on the checkbox in the export feature "Export files that the pages link to"

So I know it copies the structure of what ever you have selected to Export, but does it copy the media files that are attached to that page? So if I have an image feild on a one of the pages it will back up the actual media file? and if so where is it? as when you do an export you just get a single file to restore, is the media file somehow included in the restore file? (assuming I am NOT storing images in the database, becuase we are not doing that) and then when I import it to another enviroment does it copy the image in to the app_data path?

2. We are currently using the defult path so /App_Data/blobs but when you actually see an image in the HTML of a rendered page you get a link like /globalassets/folder/image.svg
Do you know how that works?

3. I had a look at the documentation around mirroring and it states:
You can install mirroring only on Episerver CMS 7.5 (through the Deployment Center). If you want mirroring with the latest Episerver version, install a CMS 7.5 site with mirroring, and then upgrade to the latest CMS through NuGetbecause there is no NuGet package for mirroring functionality

We are alreading running the latest version of episerver, does this mean I have to down grade then upgrade again to use this approach?

4. Is manually backing up the live database and restoring it to other enviroments, then copying the media manually if they do not point to a shared location a pretty typical episerver task when developing projects?

Just to get to know episerver a bit more and use the mirroring I was thinking of setting up two sites on my local machine and trying to set mirring up, but does that mean I have to install 7.5? Why isn't there a version that can be used on the latest version of Episerver? if you could just clarify the points above too I would be very greatful.

Good morning Ayo,

1. Episerver does copy the attached media when you export import of the page.  That is the beauty of the export and import feature.  The media file does contain the images/assets that are attached to the page.  A quick rename of teh ExportedFile.episerverdata to exportedfile.zip you can actually see the package and assets in that file.  Based on the blob provider(in your case (filesystem /blobs), it will upload the file in episerver import process and then the provider takes over and saves it to the blobs folder.  So the export import feature as long as you check the "export files the page links to" checkbox, it will handle the assets for you.
2. The  reason you see globalassets/folder/image.svg in the url is the url rewriter or should i say routing in episerver.  EPiserver links to provide a friendly SEO url for all content that is Url addressable, they use a router for the handling of urls.  By default, when you get the icontent item, the softlink is a very long ugly url like /link/34893024832jkl32u4u933223/xxx.aspx.  What episerver does is turns that into the friendly url via routing and urlrewriter.  So in this case you mentioned, anything that lives under "For All Sites" it will get the globalassets folder and then follow the structure of the folders below for your file.  Since image.sgv is the url segment for that file, that is the filename it uses. 
   For media under "For this page", it uses contentassets/folder/folder/filename.extension to handle the url.
3. backing up and restoring is pretty common in the episerver world.  We even do that on the DXC platform to move production back to development and then move the assets from azure storage production to the azure storage development container.  So yes, this is pretty common.

You really don't have to install 7.5.  You need to use deployment manager out of the install to create the mirroring items.  Then you can use upgrade via nuget from there.  Hopefully that helps.