Cualquier problema potencial para hacer una copia de seguridad de los GeoPackages abiertos utilizando la rutina de Python

Question

Estoy buscando crear una rutina simple de respaldo, usando Python estándar, para respaldar mis GeoPackages. La rutina debe ser lo suficientemente flexible como para poder respaldar el geopackage, mientras está abierto (en modo de lectura). Aunque no tengo la necesidad de hacer una copia de seguridad en modo de escritura, estoy seguro de que esto se encontrará en algún momento. Mi diseño será simplemente copiar y comprimir una lista de GeoPackages que tengo aquí.

Así que mis preguntas son

• ¿Existe algún problema conocido al copiar/comprimir un GeoPackage que esté en modo de lectura (tanto desde la perspectiva del usuario final como de la rutina de copia de seguridad)?
• Como en el caso anterior, pero si el GeoPackage está en modo de escritura?

Además, estoy estudiando la posibilidad de escribir una simple rutina en Python (en realidad, probablemente buscaré una en línea, tan simple como puede ser), sin embargo, ¿hay alguna facilidad conocida dentro de QGIS u otro software que pueda facilitar mejor este requisito?

Answer 1

Los GeoPackages son archivos SQLite y, por tanto, las técnicas de copia de seguridad de archivos SQLite deberían aplicarse aquí.

Los documentos de SQLite tienen alguna información sobre las copias de seguridad aquí: https://sqlite.org/backup.html y da un par de métodos:

1. Utilizar la API de copia de seguridad de SQLite desde el código C. No estoy seguro de si hay enlaces de Python para esto.
2. Abra la base de datos y ejecute VACUUM INTO 'backup.gpkg'; - esto copiará la base de datos abierta a una nueva llamada backup.gpkg así como aspirarlo para eliminar los datos marcados como borrados.

Si estos métodos se ejecutan sin errores (es decir, sin que aparezca el mensaje "Disco lleno" o se desconecte el enchufe), el archivo de salida resultante debería ser una base de datos SQLite válida y, por lo tanto, una copia de seguridad válida de GeoPackage del original. También debería ser consistente (es decir, todas las operaciones atómicas se completan), y debería tener un impacto menor en otros procesos que utilizan la base de datos (es decir, no los bloqueará durante largos períodos de tiempo).

El VACUUM INTO requiere una versión más reciente de SQLite herramientas de las que tenía en mi sistema ahora mismo, pero descargar y ejecutar la última es realmente fácil: sólo tuve que conseguir los binarios de Linux, que eran un par de megabytes.

No debería importar si la base de datos está siendo escrita por otro proceso - ese proceso puede continuar escribiendo mientras se realiza la copia de seguridad, pero la cantidad de contenido escrito actual que se respalda dependerá del punto exacto en que se realiza la copia de seguridad. En cualquier caso, la propiedad de consistencia asegurará que su copia de seguridad es completa hasta el nivel transaccional del proceso de escritura.

Answer 2

Es posible que obtenga más y mejores respuestas de http://dba.stackexchange.com/ porque al fin y al cabo GeoPackage no es más que una base de datos SQLite.

Un método sencillo de copia de seguridad en el entorno GIS sería ejecutar sólo

ogr2ogr -f gpkg backup.gpkg input.gpkg .

Lo mismo se puede hacer con los enlaces de GDAL Python sin usar el ejecutable ogr2ogr. Debido a que los datos se escriben en una nueva base de datos que efectivamente vacía la base de datos por el mismo. Pero si el GeoPackage está en uso en modo lectura-escritura y hay transacciones pendientes no estoy seguro de qué datos se almacenan en la copia.

Si prefiere jugar con los archivos y sabe que la base de datos está abierta como de sólo lectura, es seguro hacer una copia de seguridad sólo del archivo db principal .gpkg. Todos los posibles archivos temporales https://sqlite.org/tempfiles.html puede ser omitido.

También puede hacer una copia de seguridad sólo del archivo .gpkg cuando la base de datos se abre como lectura-escritura, pero entonces no es seguro lo que contendrá su copia de seguridad. Una mejor opción es respaldar también los archivos del diario. Lo que son depende del modo de diario que la base de datos de GeoPackage esté usando.

Si la base de datos de GeoPackage está utilizando diarios de retroceso https://sqlite.org/lockingv3.html#rollback podría comprobar si el archivo del diario existe. Si no hay un archivo de diario, entonces el .gpkg está actualizado y puede hacer una copia de seguridad sólo de eso. Si hay un archivo del diario puede hacer una copia de seguridad también de eso o hacer un bucle y esperar hasta que el diario desaparezca. Normalmente son sólo segundos, pero a veces puede significar una larga espera.

Si GeoPackage está configurado para utilizar el registro de escritura anticipada https://sqlite.org/wal.html también se crea un archivo sidecar wal cuando la base de datos se abre como de sólo lectura. Por lo que sé, QGIS cambia los GeoPackages por WAL. El archivo wal desaparece sólo una vez que la última conexión a la base de datos se cierra correctamente. En el modo de diario rollback se garantiza que el .gpkg contiene todos los cambios si no hay un archivo de diario pero en el modo WAL no se puede usar esa lógica. Si usted controla el sistema y sabe que GeoPackage está abierto como sólo lectura, puede omitir el archivo wal, ya que éste contiene las transacciones pendientes. De lo contrario, debería hacer una copia de seguridad de los archivos .gpkg y wal y shm juntos y la copia de seguridad contendría una instantánea de ese momento exacto.

Su sistema de copia de seguridad para el caso de lectura-escritura también podría copiar el .gpkg y el archivo de diario o wal+shm en un lugar temporal y luego abrir y cerrar la base de datos. Haciendo esto, los cambios pendientes se integrarían en el archivo principal de la base de datos, los archivos sidecar desaparecerían, y sólo tendrías el archivo .gpkg para poner en la copia de seguridad final.