Creé un script para realizar una copia de seguridad física de una base de datos Postgresql 9.0.8 siguiendo la receta "Copia de seguridad de base de datos física independiente en caliente" en el Libro de recetas de administración de PostgreSQL 9 (Riggs/Krosing), pero lo adapté para Windows Server 2008 R2. .
Para el paso 4 de la receta que usa rsync para copiar todos los archivos de datos (excluyendo el directorio pg_xlog), estoy usando robocopy.exe (ya que rsync es una utilidad *nix y estoy usando Windows). El problema es que, a menudo, uno de los archivos no se puede copiar y el resultado es "Acceso denegado". Copiar el archivo a mano falla con "Acceso denegado"largodespués de que el script de respaldo haya fallado, por lo que no se trata de un problema intermitente que pueda volver a intentarse. El archivo se puede copiar solo después de reiniciar el proceso PostgreSQL. Siempre es un archivo diferente. Anoche fue %PGDATADIR%\5432\base\24609\38122.
Me gustaría saber si ha experimentado esto y qué hizo para solucionarlo. Estoy considerando:
- Reinicie el servidor PostgreSQL justo antes de realizar la copia de seguridad (admito que esto es un truco)
- Usar algún tipo de utilidad que pueda copiar archivos abiertos como VSHADOW, DISKSHADOW y hobocopy (nota: no robocopy)
- ¿Quizás haya alguna forma de indicarle a PostgreSQL que libere todos los bloqueos?
- [agregado] ver a continuación: parece que agregar "aspiración" regular elimina el síntoma
Respuesta1
Bien, lo primero es lo primero: guarda tu libro de cocina. En lugar de eso ve a leerla sección del manual de Postgres sobre copias de seguridad. Lea el capítulo completo; no es tan largo.
(Probablemente notarás algunas similitudes entre esto y el libro; la mayoría de los libros de Postgres son solo versiones mejoradas del manual, pero siempre debes trabajar con el manual como referencia principal).
Toda la terminología que usaré a continuación proviene del manual (por lo que si pensaba que podía omitir la tarea de lectura, no puede; si lo hace, es probable que quede terriblemente confundido).
Ahora, para su problema real: una solución Unix a menudo no es directamente portátil a Windows, y este es uno de esos casos: un sistema *nix felizmente tomará un archivo que está siendo manipulado; Windows arroja el error que está viendo.
La forma de abordar esto depende del tipo de copia de seguridad que esté realizando.
Copias de seguridad a nivel de sistema de archivos
Si estás haciendo un"copia de seguridad a nivel del sistema de archivos"túdebeapague el servidor. Punto final, fin de la discusión, no hay otras opciones. La base de datos debe cerrarse por completo para que ese tipo de copia de seguridad sea confiable (y si la copia de seguridad que está obteniendo no es confiable, ¿cuál es el punto?).
Archivado continuo/Recuperación en un momento dado y servidores esclavos
Si estás haciendo uncopia de seguridad basecomo parte de la configuraciónRecuperación en un momento dadoy envío de troncos tienes dos opciones:
- Apague el servidor de todos modos.
- Utilice una herramienta que pueda copiar archivos abiertos (opción (2) de su pregunta)
Luego, proceda según el resto de la documentación para Recuperación en un momento dado/Envío de registros, creando un servidor esclavo.
Cuando desee copiar su servidor de base de datos al disco, simplemente detenga el esclavo, haga una copia de seguridad y reinícielo; el mundo sigue encendiendo su servidor maestro y el esclavo se pondrá al día con lo que se perdió cuando se reinicie.
También puede utilizar la copia de seguridad base más los registros de transacciones enrollados que normalmente enviaría al esclavo como una buena copia de seguridad confiable de la base de datos. Esto parecería ser lo más parecido a lo que está tratando de lograr en su pregunta, pero recomendaría la copia de seguridad esclava que describí en su lugar: más beneficios (tiene un modo de espera activo) y menos trabajo para el servidor maestro (no puntos de control adicionales para actualizar el registro de transacciones de la copia de seguridad).
Algo más
Si nada de lo anterior te atrae, estás prácticamente estancado usandoVolcados de SQL.
Hay desventajas: Postgres tiene que bloquear cada tabla cuando se descarga (lo que significa que las escrituras en su base de datos se bloquearán), y los volcados de SQL son más lentos que las otras opciones.
Si su base de datos es de tamaño real, no recomendaría este método.