2011-04-03 23 views
52

Actualmente estoy usando pg_dump canalizado a gzip canalizado a split. Pero el problema con esto es que todos los archivos de salida siempre se cambian. Entonces, la copia de seguridad basada en la suma de comprobación siempre copia todos los datos.El mejor método para la copia de seguridad incremental de PostgreSQL

¿Hay alguna otra manera de realizar una copia de seguridad incremental de una base de datos PostgreSQL, donde se puede restaurar una base de datos completa a partir de los datos de la copia de seguridad?

Por ejemplo, si pg_dump pudiera hacer todo absolutamente ordenado, entonces todos los cambios se aplican solo al final del volcado, o similar.

+0

¿Has encontrado el s ¿solución? También tengo el mismo requisito, es decir, una copia de seguridad incremental en PostgreSQL. He revisado muchos artículos y sitios web, pero no pude encontrar una manera clara de hacer copias de seguridad incrementales en PostgreSQL. ¿PostgreSQL admite copia de seguridad incremental de forma independiente sin herramientas de terceros como pg rman? Por favor ayúdame con esto. Gracias. – Suniel

Respuesta

52

Actualización:Check out Barman para una forma más fácil de configurar el archivo WAL para la copia de seguridad.

Puede usar el método PostgreSQL's continuous WAL archiving. Primero debe configurar wal_level=archive, luego hacer una copia de seguridad completa del sistema de archivos (entre emitir los comandos pg_start_backup() y pg_stop_backup()) y luego simplemente copiar los archivos WAL más nuevos configurando la opción archive_command.

Ventajas:

  • incremental, los archivos WAL incluyen todo lo necesario para restaurar el estado actual de la base de datos
  • Casi ninguna sobrecarga, la copia de archivos WAL es barato
  • Puede restaurar la base de datos en cualquier punto en el tiempo (esta función se llama PITR o recuperación puntual)

Desventajas:

  • más complicados de instalar que pg_dump
  • La copia de seguridad completa será mucho más grande que un pg_dump porque todas las estructuras de tablas internas y los índices se incluyen
  • no funciona bien para las bases de datos de escritura-pesado, ya que la recuperación tomará un largo tiempo.

hay algunas herramientas tales como pitrtools y omnipitr que puede simplificar la creación y restauración de estas configuraciones. Pero no los he usado yo mismo.

+1

Ahora mismo estoy jugando con esto y descubro que incluso en Windows (aunque la mayoría de los documentos son muy pesados), esto no está nada mal sin las herramientas –

+0

+1 para Barman, ya que ofrece una buena solución lista para usar. –

+2

Haciendo ping para cualquier actualización/desarrollo más reciente. –

1

Otro método es realizar copias de seguridad en texto plano y usar rdiff para crear diferencias incrementales.

+5

No puedo imaginar hacer eso para una base de datos 5G, menos aún para las de 50G. – Jerry

+2

Lo he usado en dbs mucho más grandes que 50G en el pasado usando instantáneas del mismo directorio de datos. Pero sí, una vez que una copia de seguridad de prueba simple comienza a hacerse grande y difícil de manejar, es una buena idea utilizar algún otro método. –

+1

No sé cómo funciona exactamente el barman, pero el archivo WAL no guarda los índices hasta donde yo sé (http://www.postgresql.org/docs/9.2/static/continuous-archiving.html#CONTINUOUS-ARCHIVING- CAVEATS). – Bladt

4

También puedes ver http://www.pgbackrest.org

pgBackrest es otra herramienta de copia de seguridad para PostgreSQL que se deben evaluar, ya que soporta:

  • copia de seguridad en paralelo (probado a escala casi linealmente hasta 32 núcleos, pero probablemente puede ir mucho más lejos ...)
  • copias de seguridad comprimidas en reposo
  • incremental y diferencial (comprimido!) Copias de seguridad de
  • la compresión de secuencias (los datos se comprimen sólo una vez en la fuente y luego se transfiere a través de la red y almacena)
  • paralelo, delta restaurar (capacidad de actualizar una copia anterior a la última)
  • Apoya plenamente los espacios de tabla
  • rotación de copia de seguridad y archivo de caducidad
  • Capacidad de reanudar las copias de seguridad que fallaron por alguna razón
  • etc, etc ..
+0

cómo hacer una copia de seguridad desde el modo de espera? Tengo /etc/pgbackrest.conf diciendo que backup-standby = y, archive-async = y y remotebacup ini tag de configuración en el que contienen db-port = 5433 y db-host = lanip (192.168.0.3). Invocando siempre/opt/perlroot/bin/perl/opt/perlroot/bin/pgbackrest --stanza = remotebackup stanza-create obtuve el error 124 proceso remoto terminado en 192.168.0.3 estado de salida 255: Permiso de clave pública denegada. Pero extrañamente invocando desde sudo stand -u postgres ssh 192.168.0.3 funciona bien. Agregar cmd-ssh =/usr/bin/sudo -u postgres/usr/bin/ssh -vv no funcionó :( – user3453753

+0

La copia de seguridad desde el modo de espera se trata en la documentación de pgbackrest y principalmente consiste en configurar las réplicas en el pgbackrest.conf file. En cuanto a su permiso denegado, realmente no puedo hablar, pero es probable que tenga una configuración incorrecta en su sistema con respecto a las claves SSH. –

Cuestiones relacionadas