Esta pregunta abarca tres aspectos distintos, cada uno con una respuesta diferente. Una eliminación realizada dentro de la aplicación se puede deshacer: nada se borra realmente, la fila pasa a una papelera desde la que un botón la restaura. Sus datos salen cuando usted lo desea, ya que cada lista dispone de su propio botón de exportación. Pero la base de datos de una aplicación desplegada NO se respalda mediante ningún mecanismo automático del producto: no existe ningún comando de respaldo en toda la cadena de despliegue, y corresponde al proveedor de alojamiento implementarlo. Dicho de otro modo: un clic accidental se recupera fácilmente con un solo clic en « Restaurar », pero una base de datos perdida no se recupera Esta página define con precisión dónde está esa línea divisoria, para que usted formule las preguntas adecuadas antes de introducir datos reales.
Eliminar dentro de su aplicación no destruye nada
El botón Eliminar no elimina: marca la fila como eliminada mediante una columna específica. Así desaparece de las listas, los totales y los indicadores, pero sigue estando en la base de datos. En cuanto se elimina una fila, aparece una tarjeta «Papelera» en la sección de Ajustes, con un botón «Restaurar». Esto se puede comprobar directamente en el código entregado: ninguna de las rutas generadas ejecuta una eliminación definitiva en la base de datos.
Además, la confirmación se realiza en dos pasos: un primer clic activa la eliminación y un segundo la confirma, en lugar de usar el diálogo de confirmación estándar del navegador. De este modo, el caso más frecuente, el clic accidental al final de la jornada, se revierte en treinta segundos y sin necesidad de llamar a nadie. Es, además, la única de las tres capas que la aplicación gestiona por completo de forma autónoma, y por eso aparece en primer lugar.
Exportar sus datos cuando quiera
Cada lista incluye un botón para exportar en formato CSV. Este exporta únicamente las filas que usted VE, filtradas por la búsqueda y los filtros activos, y la etiqueta del botón indica cuántas filas se van a exportar: nunca se exportan en silencio datos que no están visibles en pantalla. El archivo se genera para abrirse correctamente en una hoja de cálculo en español, sin la línea de caracteres con acentos rotos que suele afectar a las exportaciones habituales.
Se trata de una copia que usted posee, y debe denominarse con claridad: no es un respaldo en sentido técnico. Un archivo CSV no restaura una aplicación: no contiene ni las relaciones entre sus tablas, ni el historial, ni los registros eliminados. Su función es devolverle el control: abrir sus cifras en una hoja de cálculo, enviárselas a su contable o alimentar otra herramienta. Es lo que evita que quede atrapado, no lo que lo protege ante una avería.
Lo que NO se hace, y que usted debe decidir
Cuando su aplicación se despliega, recibe su propia base de datos PostgreSQL. Y nada en la cadena de despliegue la respalda: no hay ningún comando de respaldo en el código que despliega las aplicaciones. No es una omisión que se pase por alto, sino una frontera clara: la responsabilidad del respaldo depende del entorno donde se ejecute la aplicación, y corresponde, por tanto, a quien la aloje, ya sea usted, su proveedor de servicios o nosotros mismos, si somos quienes la alojamos.
Bastan tres preguntas para definir esta responsabilidad, y deben plantearse antes de introducir datos reales. ¿Quién genera la copia y con qué frecuencia? ¿Dónde se almacena, en un lugar distinto de la máquina que ejecuta la aplicación, para evitar que una misma incidencia afecte a ambas? Y, sobre todo: ¿alguien ha RESTAURADO ya a partir de esa copia? Esta tercera pregunta es la que más se olvida, y también la única que demuestra algo real: un respaldo que nunca se ha restaurado no es un respaldo, sino una suposición.
Qué cambia según el tipo de datos que introduzca
No todos los contenidos requieren el mismo nivel de protección. Para una herramienta cuyos datos se pueden reconstruir fácilmente, como un calendario semanal o un seguimiento ligero que se pueda volver a teclear en una hora, una exportación mensual archivada en algún lugar es más que suficiente. Sin embargo, para un registro que no se puede reconstruir, sus socios, el historial de sus intervenciones o sus expedientes en curso, el respaldo automático de la base de datos es un requisito previo, no una opción: nadie vuelve a escribir tres años de historial de memoria.
La buena noticia es que no hay obstáculos técnicos: el código generado usa Next.js y Prisma estándar sobre una base de datos PostgreSQL, sin formatos propietarios que dificulten su uso, y hacer copias de seguridad de una base PostgreSQL es una operación que cualquier proveedor sabe realizar. Por tanto, la pregunta nunca es «¿es posible?», sino «¿quién lo hace, desde cuándo y se ha verificado al menos una vez?».