Pensé en lo que escribiste y aquí hay algunas ideas para ti:
- Si necesita una copia de seguridad que realmente será coherente en algún momento, entonces debe usar pg_basebackup o pg_barman (internamente usa pg_basebackup); la explicación se encuentra en el enlace 1 a continuación. El último pg_basebackup 10 transmite registros WAL para que también haga una copia de seguridad de todos los cambios realizados durante la copia de seguridad. Por supuesto, esta copia de seguridad solo toma toda la instancia de PG. Por otro lado no bloquea ninguna tabla. Y si lo hace desde una instancia remota, solo causa una pequeña carga de CPU en la instancia de PG y la E/S del disco no es tan grande como sugieren algunos textos. Ver enlaces 4 sobre mis experiencias. La restauración es bastante simple:consulte el enlace 5.
- Si usa pg_dump, debe comprender que no tiene ninguna garantía de que su copia de seguridad sea realmente coherente con el momento dado; de nuevo, vea el enlace 1. Existe la posibilidad de usar una instantánea de la base de datos (vea los enlaces 2 y 3), pero incluso con él no se puede contar con una consistencia del 100%. Usamos pg_dump solo en nuestra base de datos analítica que carga nuevas solo 1 vez por día (particiones de ayer de la base de datos de producción). Puede acelerarlo con la opción paralela (funciona solo para el formato de copia de seguridad del directorio). Pero la desventaja es una carga mucho mayor en la instancia de PG:mayor uso de CPU, E/S de disco mucho mayor. Incluso si ejecuta pg_dump de forma remota, en tal caso, solo guarda la E/S del disco para guardar los archivos de copia de seguridad. Además, pg_dump necesita colocar un bloqueo de lectura en las tablas para que pueda coincidir con nuevas inserciones o con la replicación (cuando se toma en la réplica). Pero cuando su base de datos alcanza cientos de GB, incluso el volcado paralelo puede llevar horas y en ese momento tendría que cambiar a pg_basebackup de todos modos.
- pg_barman es una "versión cómoda" de pg_basebackup + que le permite evitar la pérdida de datos incluso cuando su instancia de PG falla gravemente. Ponerlo a funcionar requiere más cambios, pero definitivamente vale la pena. Deberá configurar el archivo de registro WAL (consulte el enlace 6) y si su PG es <10, deberá configurar "max_wal_senders" y "max_replication_slots" (que necesita para la replicación de todos modos) - todo está en pg-barman manual aunque descripción no es exactamente genial. pg_barman transmitirá y almacenará registros WAL incluso entre copias de seguridad, por lo que puede estar seguro de que la pérdida de datos en caso de un bloqueo muy grave será casi nula. Pero hacer que funcione puede llevar muchas horas porque las descripciones no son precisamente buenas. pg-barman realiza copias de seguridad y restauración con sus comandos.
Su base de datos tiene un tamaño de 5 GB, por lo que cualquier método de copia de seguridad será rápido. Pero debe decidir si necesita una recuperación puntual y una pérdida de datos casi nula o no, por lo tanto, si invertirá tiempo para configurar pg-barman o no.
Enlaces:
- PostgreSQL, copias de seguridad y todo necesitas saber
- Revisión para papel:14 serializable Aislamiento de instantáneas en PostgreSQL - sobre instantáneas
- Descarga paralela de bases de datos - ejemplo de cómo usar la instantánea
- experiencias pg_basebackup
- pg_basebackup - restaurar copia de seguridad tar
- Archivado de registros WAL mediante script
