Qual è il modo corretto di eseguire il backup di un geodatabase di file ESRI pubblicato su ArcGIS Server?


11

Ho un geodatabase di file ESRI (v10) pubblicato su un servizio di mappe del server arcgis. Quando il servizio è in esecuzione, fGDB è bloccato. Devo interrompere il servizio per ottenere un backup pulito? Oppure, c'è un modo per eseguire un backup tramite uno script arcpy o tramite Catalog? Attualmente sto usando Windows robocopy per trasferire fGDB su un'unità di backup. Ecco l'output che mostra i file bloccati:

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

ecc, ecc ...

Risposte:


4

Qualsiasi server dovrebbe avere un'unità shadow. È possibile utilizzare l '"unità ombra" per compattare il file geodatabase e questo rimuoverà i file .lock e riordinerà il file nel modo più efficiente. Quindi è possibile eseguire il backup di questo file. Ecco una buona coppia di buoni punti di partenza:

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

Nota: l'unità Shadow ha un altro nome di mirroring del disco

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


Ah, ho sempre pensato che la compattazione fosse per geodatabase sde. Grazie!
mogollon22,

Gestisco diversi server e nessuno di essi ha unità shadow o con mirroring, sebbene dispongano di dischi ridondanti (RAID5, Drobo) e possano sopravvivere al guasto di una o più unità senza perdita di dati. Ad ogni modo, a parte quell'obiezione, copio le fgdb con xcopy(o xxcopy ), saltando i fallimenti, e quindi compatto il risultato. Non è la soluzione migliore poiché una classe di funzionalità bloccata a causa di una sessione di modifica potrebbe essere danneggiata, ma non è diversa da un'unità shadow / mirror.
matt wilkie

2

Abbiamo diverse applicazioni Web di produzione ad alto utilizzo che vengono eseguite su FGDB sul back-end. Gli FGDB vengono spazzati via e ricostruiti con dati freschi ogni notte. Abbiamo un'app per console .NET che ho scritto basata su AGSSOM che arresta i servizi durante l'esecuzione del processo di aggiornamento. Dai un'occhiata a AGSSOM, è piuttosto elegante. Ecco alcuni dei C # che uso per fare un backup dell'attuale FGDB prima di scaricarlo:

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

Usa semplicemente Directory.CreateDirectory e FileInfo.CopyTo per copiare l'FGDB - Windows vede l'FGDB come un'altra cartella. Funziona come un campione. Quindi, al termine del processo di aggiornamento, riavviamo i servizi utilizzando l'applicazione basata su AGSSOM.


Questo è stato estremamente prezioso!
mogollon22,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.