Una estrategia de respaldo alternativa es copiar directamente los archivos que utiliza PostgreSQL para almacenar los datos en la base de datos; Section 18.2 explica dónde se encuentran estos archivos. Puedes utilizar cualquier método que prefieras para realizar respaldos del sistema de archivos; por ejemplo:
tar -cf backup.tar /usr/local/pgsql/data
Sin embargo, existen dos restricciones que hacen que este método sea poco práctico, o al menos inferior al método de pg_dump:
El servidor de la base de datos debe estar apagado para obtener un respaldo utilizable.
Las medidas a medias, como no permitir todas las conexiones, no funcionarán (en parte
porque tar y herramientas similares no toman una instantánea atómica del estado del sistema
de archivos, sino también debido a los búferes internos dentro del servidor). La información sobre cómo detener
el servidor se puede encontrar en Section 18.5. No hace falta decir que también debes
apagar el servidor antes de restaurar los datos.
Si has profundizado en los detalles del diseño del sistema de archivos de la base de datos, podrías tener la
tentación de intentar respaldar o restaurar solo ciertas tablas o bases de datos individuales desde sus
respectivos archivos o directorios. Esto no funcionará porque la información contenida
en estos archivos no es utilizable sin los archivos de registro de confirmación, pg_xact/*,
que contienen el estado de confirmación de todas las transacciones. Un archivo de tabla solo es utilizable con esta
información. Por supuesto, también es imposible restaurar solo una tabla y los datos de pg_xact
asociados porque eso dejaría inútiles a todas las demás tablas del clúster de la base de datos. Por lo tanto, los
respaldos del sistema de archivos solo funcionan para el respaldo y la restauración completos de un clúster
de bases de datos entero.
Un enfoque alternativo de respaldo del sistema de archivos es hacer una «instantánea consistente» (consistent snapshot)
del directorio de datos, si el sistema de archivos admite esa funcionalidad (y estás dispuesto a confiar en que
está implementada correctamente). El procedimiento típico es hacer una «instantánea congelada» (frozen snapshot) del
volumen que contiene la base de datos, luego copiar todo el directorio de datos (no solo partes, ver arriba) desde la
instantánea a un dispositivo de respaldo, y luego liberar la instantánea congelada. Esto funcionará incluso mientras el
servidor de la base de datos esté ejecutándose. Sin embargo, un respaldo creado de esta manera guarda los archivos de la
base de datos en un estado como si el servidor de la base de datos no se hubiera apagado correctamente; por lo tanto, cuando
inicies el servidor de la base de datos con los datos respaldados, pensará que la instancia anterior del servidor falló
y reproducirá el registro WAL. Esto no es un problema; solo tenlo en cuenta (y asegúrate de incluir los archivos WAL en
tu respaldo). Puedes realizar un CHECKPOINT antes de tomar la instantánea para reducir el tiempo de
recuperación.
Si tu base de datos está distribuida en varios sistemas de archivos, es posible que no haya forma de obtener instantáneas congeladas exactamente simultáneas de todos los volúmenes. Por ejemplo, si tus archivos de datos y el registro WAL están en discos diferentes, o si los tablespaces están en sistemas de archivos diferentes, podría no ser posible utilizar el respaldo por instantánea porque las instantáneas deben ser simultáneas. Lee la documentación de tu sistema de archivos con mucha atención antes de confiar en la técnica de instantánea consistente en tales situaciones.
Si no es posible realizar instantáneas simultáneas, una opción es apagar el servidor de la base de datos el tiempo suficiente para establecer todas las instantáneas congeladas. Otra opción es realizar un respaldo base de archivado continuo (Section 25.3.2) porque tales respaldos son inmunes a los cambios del sistema de archivos durante el respaldo. Esto requiere habilitar el archivado continuo solo durante el proceso de respaldo; la restauración se realiza mediante la recuperación de archivo continuo (Section 25.3.5).
Otra opción es utilizar rsync para realizar un respaldo del sistema de archivos. Esto se hace
ejecutando primero rsync mientras el servidor de la base de datos está funcionando, luego
apagando el servidor de la base de datos el tiempo suficiente para hacer un rsync --checksum.
(--checksum es necesario porque rsync solo tiene una granularidad de tiempo de
modificación de archivo de un segundo). El segundo rsync será más rápido que el primero,
porque tiene relativamente pocos datos que transferir, y el resultado final será consistente porque el servidor estaba
apagado. Este método permite realizar un respaldo del sistema de archivos con un tiempo de inactividad mínimo.
Ten en cuenta que un respaldo del sistema de archivos normalmente será más grande que un volcado SQL. (Por ejemplo, pg_dump no necesita volcar el contenido de los índices, sino solo los comandos para recrearlos). Sin embargo, realizar un respaldo del sistema de archivos puede ser más rápido.