Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I have an ESRI file geodatabase (v10) that is published to an arcgis server map service. When the service is running, the fGDB is locked. Do I need to stop the service to get a clean backup? Or, is there a way to perform a backup through an arcpy script or through Catalog? I'm currently using Windows robocopy to transfer the fGDB to a backup drive. Here's the output showing the locked files:

 New File           0 Bikepaths.CFP0026.4968.5140.sr.lock
 New File           0 BuildingFootprints.CFP0026.4968.5140.sr.lock

etc, etc...

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

Any server should have a shadow drive. You can use the 'shadow drive' to compact the file geodatabase and that will remove the .lock files and re-order the file in the most efficient way. Then you can back this file up. Here is a good couple good starting points:

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/File_geodatabases_compressing_vs_compacting/003n0000007r000000/

Note: Shadow drive has another name of disk mirroring

http://en.wikipedia.org/wiki/Disk_mirroring

share|improve this answer
    
Ah, I always assumed compacting was for sde geodatabases. Thanks! –  mogollon22 Oct 27 '10 at 20:45
    
I manage several servers and none of them have shadow or mirrored drives, although they do have redundant disks (RAID5, Drobo) and can survive the failure of one or more drives without data loss. Anyhow that objection aside, I copy the fgdb's with xcopy (or xxcopy), skipping the failures, and then compact the result. It's not the best solution as a feature class locked because of an edit session could get corrupted, but that's no different from a shadow/mirror drive. –  matt wilkie May 31 '11 at 21:57
add comment

We have several high usage production web applications that run on FGDBs on the backend. The FGDBs get wiped out and rebuilt with fresh data nightly. We have a .NET console app I wrote that is based on AGSSOM that stops the services while the update process runs. Check out AGSSOM, it's pretty slick. Here's some of the C# I use to make a backup of the current FGDB before I blow it away:

// Only archive it FGDB already exists, if this is first run, then nothing to archive
            if (Directory.Exists(String.Concat(c.fgdbDir, @"\", kvp.Key[0], ".gdb")))
            {
                c.msg = String.Concat(Environment.NewLine, "Archiving data for ", kvp.Key[0], " - ",
                                      DateTime.Now.ToString("MM/dd/yyyy hh:mm:ss tt"));
                Messaging.Log(c.msg, c.lw);
                // Create the FGDB folder in archive dir if not already there
                if (!Directory.Exists(String.Concat(c.fgdbArchiveDir, @"\", kvp.Key[0], ".gdb")))
                {
                    Directory.CreateDirectory(String.Concat(c.fgdbArchiveDir, @"\", kvp.Key[0], ".gdb"));
                    // Now copy from clips to archive
                    foreach (FileInfo fi in source.GetFiles())
                    {
                        fi.CopyTo(System.IO.Path.Combine(target.ToString(), fi.Name), true);
                    }
                }
            }

It just uses Directory.CreateDirectory and FileInfo.CopyTo to copy the FGDB - Windows sees the FGDB as just another folder. Works like a champ. Then, after the update process is complete, we start the services again using the AGSSOM-based application.

share|improve this answer
    
This was extremely valuable! –  mogollon22 Oct 27 '10 at 20:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.