Backups for Collector

1223
3
04-27-2016 07:58 AM
Status: Open
PaulBreier
New Contributor II

We often use Collector for Windows for long periods of time in areas where syncing is not possible. If our device experiences a failure in between syncs, we have the potential to experience significant data loss. It would be nice if collector had an option to back up its edits to a portable drive.

In the meantime, with some help from tech support, we were able to come up with the following workflow for backing up Collector files to a portable drive, and then restoring these files as a single file geodatabase. This workflow, which we were able to capture in a Python script, is the following:

  1. Navigate to C:\Users\[user]\AppData\Local\Packages\Esri.CollectorforArcGIS_[string]\LocalState\[string]
  2. Copy the *.geodatabase files from the folder mentioned in Step 1 to a portable flash drive. Collector may use several geodatabases to track edits. Therefore, it’s important to copy all *.geodatabase files in this folder.
  3. Use the “Copy Runtime Geodatabase to File Geodatabase” tool to create a file geodatabase from the *.geodatabase files
Tags (2)
3 Comments
ScottPrindle

Hello Paul,

Thank you for submitting this idea. Since the runtime geodatabase in Collector is a replica of the original dataset, it would be best to do all you can to troubleshoot the sync failure before resorting to the Copy Runtime Geodatabse to File Geodatabase tool. While this tool can be very useful to convert your seemingly unsyncable data to a usable format, there are some things to keep in mind when using it:

  1. The replica will remain open on the service, and it will take additional workflows to bring your data from a file geodatabase back into the service.
  2. A file geodatabase does not keep a record of deletes that were done in the runtime geodatabase. The runtime geodatabase uses archiving and a more elaborate table structure to record adds, updates, and deletes. The Copy Runtime Geodatabase to File Geodatabase tool will maintain the current view of the data, which means only adds and updates will be copied over.

When reaching out to technical support for sync issues, try to keep in mind what kinds of edits were done before the sync failure. What geometry and attribution was being collected? Was the field worker doing only adds, only updates, only deletes, or a combination of editing? Were attachments being collected, if so, how many per feature? Did the device freeze or reboot unexpectedly, or was it dropped?

The Copy Runtime Geodatabase to File Geodatabase tool should be used sparingly due to the concerns listed above. If anyone voting for this idea has other scenarios where you need to grab the data from your device, please comment to share your use case.

Thanks,

Scott

AdamInglis1

Hi Scott, 

We have similar desire to back up field collected data from our iPads to laptops when crews are operating in a disconnected environment for an extended period of time.  Our concern is not so much that the sync will fail once they are back in a connected environment, but the potential loss of field collected data due to equipment damage/loss while in the field.  If a worker drops an iPad in stream 7 days into a field trip that is a lot of expensive to collect data lost.

It would be nice to have the reassurance that workers could backup their data daily in camp on a laptop and only use that backup in the rare case that their iPad was lost/damaged.

CollinGrove

We're in the same boat with urban search and rescue. I've experienced many errors while synchronizing over slow or lagged internet connections (satellite). Crews are collecting hundreds of points every day that I hate losing because of errors. A way to back up that data on a computer prior to syncing would be a huge benefit.