Preguntas frecuentes

Encuentre respuestas a las preguntas más habituales sobre Databasus, incluidas la instalación, la configuración y las estrategias de copia de seguridad.

¿Por qué Databasus no usa el formato de volcado SQL plano para las copias de seguridad lógicas de PostgreSQL?

Para las copias lógicas, Databasus usa el formato personalizado de pg_dump con compresión zstd de nivel 5 en lugar del formato SQL plano porque ofrece el equilibrio más eficiente entre:

• Velocidad de creación de la copia
• Velocidad de restauración
• Compresión del tamaño del archivo (hasta 20 veces más pequeño que el formato SQL plano)

Esta decisión se tomó tras pruebas y comparativas exhaustivas de distintos formatos de copia y métodos de compresión de PostgreSQL. Puede leer más sobre las pruebas aquí: PostgreSQL backups: comparing pg_dump speed in different formats and with different compression.

Databasus no incluirá el formato de volcado SQL plano, porque:

• la variedad extra perjudica la experiencia de uso;
• hace más difícil mantener el código;
• el formato de volcado actual sirve para el 99% de los casos

¿Dónde queda instalado Databasus si se instala con el script .sh?

Databasus se instala en el directorio /opt/databasus/.

¿Cómo funcionan las copias físicas y PITR (Point-in-Time Recovery)?

Databasus ejecuta las copias físicas de forma remota desde su propio host, conectándose a su PostgreSQL por el protocolo de replicación estándar, así que no hace falta instalar nada en el servidor de la base de datos. Si la base de datos está en una red cerrada, Databasus puede alcanzarla mediante un túnel SSH hacia un host interno o un bastión, por lo que la base de datos nunca tiene que exponerse públicamente.

Cómo funcionan las copias:

• Las copias completas se crean con pg_basebackup, transmitidas directamente a Databasus
• Las incrementales a nivel de bloque usan pg_basebackup --incremental, donde los resúmenes de WAL del servidor de PostgreSQL 17 (summarize_wal = on) rastrean los cambios para transferir solo los bloques modificados
• El WAL se transmite de forma continua con pg_receivewal para mantener completa la cadena de recuperación entre copias
• Las copias físicas requieren PostgreSQL 17 o superior; en versiones anteriores se usan las copias lógicas con pg_dump

Cómo funciona la restauración:

• pg_combinebackup reconstruye un directorio de datos ejecutable a partir de la copia completa y su cadena incremental
• PostgreSQL luego reproduce el WAL hasta el momento objetivo que elija, de modo que puede restaurar a cualquier segundo entre copias
• Al arrancar PostgreSQL, este termina la recuperación, se promociona a primario y reanuda el funcionamiento normal

Por qué usamos las copias nativas de PG 17:

• Reutilizan la propia maquinaria de respaldo de PostgreSQL en lugar de reinventarla, así que obtiene internos probados con miles de tests y casos límite a sus espaldas
• Funcionan con bases de datos remotas, incluidos servicios gestionados como Amazon RDS y Google Cloud SQL, que exponen el protocolo de replicación pero prohíben instalar software en el host
• Dan una pérdida de datos casi nula: puede restaurar a cualquier segundo entre copias

¿Por qué Databasus abandonó las copias basadas en agente?

Una versión anterior de Databasus incluía un agente de respaldo: un binario que se ejecutaba en el host de la base de datos para transmitir WAL y crear copias físicas localmente. Esa primera implementación resultó ser un error, y la eliminamos. Las copias físicas ahora se ejecutan de forma remota desde el host de Databasus, como se describe arriba.

Por qué el agente era el enfoque equivocado:

• Era una implementación ingenua que solo copiaba WAL sobre copias completas, lo que llevaba a un RTO largo
• Los usuarios tenían que configurar tanto Databasus como un agente separado, cuando hacerlo todo de forma remota desde un solo lugar es mucho más simple
• Como el agente vivía fuera del sistema principal, era difícil cubrir todos los casos de prueba
• En realidad solo hay un problema que un agente resuelve: alcanzar una base de datos que no es accesible desde fuera. Para el 99% de los usuarios eso ya se resuelve ejecutando Databasus dentro de la red privada o conectando por SSH, así que el agente reinventaba la rueda y complicaba mucho más de lo necesario un problema simple
• No podía ejecutarse en bases de datos gestionadas como RDS y Cloud SQL, que prohíben instalar software en el host pero ya exponen el protocolo de replicación, así que de todos modos hacía falta una vía remota
• También traía muchos casos límite. Las conexiones rotas, la gestión de las actualizaciones del agente y la recopilación de registros de un proceso separado eran dolorosas, y cuantas menos piezas móviles tiene un sistema, más fiable es en el uso diario

Nos aseguramos de que las copias existentes queden a salvo. Si actualiza desde una versión que aún tiene copias de agente, Databasus no lo hará en silencio: le avisa del cambio y le deja quedarse en la versión 3.42.0 soportada o eliminar las copias de agente antiguas antes de actualizar. La implementación basada en agente sigue disponible hasta la versión 3.42.0 y seguirá funcionando durante mucho tiempo, así que nada se rompe.

Puede leer el razonamiento completo en los registros de decisiones de arquitectura: ADR-0008: PG17-native backups with mandatory WAL summary y ADR-0009: remote physical backups instead of agents.

¿Cómo se usa la IA en el desarrollo de Databasus?

En los issues y discusiones ha habido preguntas sobre el uso de IA en el desarrollo del proyecto. Como el proyecto se centra en la seguridad, la fiabilidad y el uso en producción, es importante explicar cómo se usa la IA en el proceso de desarrollo.

La IA se usa como ayudante para:

• Verificar la calidad del código y buscar vulnerabilidades
• Limpiar y mejorar la documentación, los comentarios y el código
• Asistir durante el desarrollo
• Revisar de nuevo los PR y commits después de la revisión humana

La IA NO se usa para:

• Escribir código completo
• El enfoque de "vibe code"
• Código sin verificación línea por línea por un humano
• Código sin tests

El proyecto tiene:

• Cobertura de tests sólida (tanto unitarios como de integración)
• Automatización con CI/CD, con tests y linting para garantizar la calidad del código
• Verificación por desarrolladores con experiencia en proyectos grandes y seguros

Así que la IA es solo un asistente y una herramienta para que los desarrolladores aumenten la productividad y garanticen la calidad del código. El trabajo lo hacen los desarrolladores.

Además, no distinguimos entre mal código humano y vibe code de IA. Cualquier código debe cumplir requisitos estrictos antes de fusionarse, para que el proyecto siga siendo mantenible.

Incluso si el código está escrito a mano por un humano, no está garantizado que se fusione. El vibe code no está permitido en absoluto y todos esos PR se rechazan por defecto (vea la guía de contribución).

También destacamos la resolución rápida de issues y el reporte de vulnerabilidades de seguridad.

¿Cómo respaldar el propio Databasus?

Si quiere respaldar su instancia de Databasus (incluidas todas las configuraciones, bases de datos y credenciales), siga estos pasos:

1. Vaya a /opt/databasus (o la carpeta donde instaló Databasus)
2. Entre en el directorio databasus-data

Necesita respaldar:

• secret.key — clave de cifrado de sus credenciales
• /pgdata — base de datos PostgreSQL interna de Databasus que contiene todas sus configuraciones y los metadatos de las copias

Si usa almacenamiento local para las copias, también puede respaldar la carpeta backups.

Importante: hay dos escenarios de recuperación distintos:

• Recuperar copias sin la interfaz de Databasus: puede recuperar las copias de sus bases de datos usando solo el archivo secret.key, sin necesitar Databasus ni sus datos internos. Vea la guía de recuperación manual para instrucciones detalladas.
• Restaurar la interfaz de Databasus y todas las configuraciones: si quiere restaurar la interfaz de Databasus con todas sus configuraciones, copias programadas e historial, necesita respaldar tanto secret.key como la carpeta /pgdata (que contiene los metadatos de cifrado y todas las configuraciones de Databasus).

Para restaurar Databasus en otro servidor: simplemente recree la estructura de la carpeta databasus-data con los archivos respaldados y arranque Databasus.

¿Cómo apoyan a Databasus los programas de código abierto de Anthropic y OpenAI?

En marzo de 2026, Databasus fue aceptado tanto en Claude for Open Source de Anthropic como en Codex for Open Source de OpenAI. Para nosotros es muy valioso que el proyecto haya sido reconocido como software de código abierto importante para la industria por dos de las empresas de IA líderes del mundo, sobre todo dados los altos requisitos de elegibilidad de ambos programas.

¿Qué significa para los usuarios? Ambos programas evalúan los proyectos de forma independiente antes de aceptarlos. Y gracias al acceso ilimitado a las últimas IA tenemos una calidad de código mayor, revisiones de seguridad más rápidas y un desarrollo activo continuo.

A pesar de tener acceso a estos programas, Databasus mantiene reglas estrictas de uso de IA, tal como se describe en la sección sobre el uso de IA. Todo el código requiere verificación humana línea por línea, cobertura de tests completa y revisión por desarrolladores experimentados. El vibe coding no está permitido. La IA sigue siendo una herramienta para los desarrolladores, no un reemplazo del juicio humano.