¿Cuál es la forma correcta de hacer una copia de seguridad de una geodatabase de archivos ESRI que se publica en ArcGIS Server?

11

Tengo una geodatabase de archivos ESRI (v10) que se publica en un servicio de mapas del servidor arcgis. Cuando el servicio se está ejecutando, el fGDB está bloqueado. ¿Necesito detener el servicio para obtener una copia de seguridad limpia? O, ¿hay alguna forma de realizar una copia de seguridad a través de un script arcpy o mediante el Catálogo? Actualmente estoy usando Windows robocopy para transferir el fGDB a una unidad de respaldo. Aquí está la salida que muestra los archivos bloqueados:

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

etcétera etcétera...

arcgis-server esri-geodatabase

— mogollon22
fuente

4

Cualquier servidor debe tener una unidad secundaria. Puede usar la 'unidad de sombra' para compactar la geodatabase de archivos y eso eliminará los archivos .lock y volverá a ordenar el archivo de la manera más eficiente. Entonces puede hacer una copia de seguridad de este archivo. Aquí hay un buen par de buenos puntos de partida:

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

Nota: Shadow Drive tiene otro nombre de duplicación de disco

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

— Mapperz
fuente

Ah, siempre supuse que la compactación era para geodatabases sde. ¡Gracias!

— mogollon22

Administro varios servidores y ninguno de ellos tiene unidades duplicadas o duplicadas, aunque sí tienen discos redundantes (RAID5, Drobo) y pueden sobrevivir a la falla de una o más unidades sin pérdida de datos. De todos modos que la objeción a un lado, con la copia del FGDB xcopy(o XXCOPY ), saltarse los fracasos, y luego compactar el resultado. No es la mejor solución ya que una clase de entidad bloqueada debido a que una sesión de edición podría corromperse, pero eso no es diferente de una unidad de sombra / espejo.

— Matt Wilkie

2

Tenemos varias aplicaciones web de producción de alto uso que se ejecutan en FGDB en el back-end. Los FGDB se aniquilan y se reconstruyen con datos nuevos todas las noches. Tenemos una aplicación de consola .NET que escribí que se basa en AGSSOM que detiene los servicios mientras se ejecuta el proceso de actualización. Mira AGSSOM, es bastante elegante. Aquí hay algunos de los C # que uso para hacer una copia de seguridad de la FGDB actual antes de eliminarla:

// 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);
                    }
                }
            }

Simplemente usa Directory.CreateDirectory y FileInfo.CopyTo para copiar el FGDB: Windows ve el FGDB como una carpeta más. Funciona como un campeón. Luego, una vez que se completa el proceso de actualización, comenzamos los servicios nuevamente usando la aplicación basada en AGSSOM.

— Chad Cooper
fuente

¡Esto fue extremadamente valioso!

— mogollon22