Com fer una còpia de seguretat de la base de dades de la teva app (i restaurar-la de veritat)

Per fer una còpia de seguretat de la base de dades de la teva app, exporta-la a un fitxer segons un calendari (per a Postgres, l'eina estàndard és pg_dump), guarda les còpies en un lloc separat de la base de dades i restaura'n regularment una en una base de dades buida per demostrar que funciona. Fes una còpia extra just abans de qualsevol canvi arriscat. La còpia del codi, sigui un repositori de GitHub o una exportació, no inclou les teves dades.

Aquesta guia és per a qui gestiona una app petita i vol deixar de preocupar-se per perdre-la. Fa servir Postgres en els exemples, perquè la majoria d'apps creades amb IA l'utilitzen, però els principis s'apliquen a qualsevol base de dades.

Què ha de cobrir una còpia de seguretat

Una app és més que la seva base de dades. Cal saber quina part protegeix cada còpia.

Què	On viu	Com fer-ne una còpia
Codi	Fitxers del projecte, Git	Sincronització amb GitHub o exportació del projecte
Dades (usuaris, registres)	La base de dades	Volcat de la base de dades amb un calendari
Fitxers pujats	Emmagatzematge d'objectes	Copia el bucket, o guarda els originals en un altre lloc
Secrets i configuració	Configuració del projecte, tauler dels proveïdors	Un gestor de contrasenyes, mantingut al dia

Les dades són la part que no pots recrear. El codi es pot tornar a escriure i la configuració es pot tornar a introduir; les comandes dels teus clients, no.

Pas 1: decideix quantes dades pots perdre

Dues preguntes marquen el teu pla de còpies:

Quantes dades recents pots permetre't perdre? Si fas una còpia un cop al dia i la base de dades falla a la nit, perds els canvis d'aquell dia. Per a una app d'hobby això és acceptable. Per a una app que rep comandes, potser no.
Quant de temps pot estar caiguda l'app mentre restaures? Una base de dades petita es restaura en minuts. Una de gran pot trigar molt més, i cal saber-ho abans de necessitar-ho.

Per a la majoria d'apps petites, una còpia automàtica diària més una manual abans dels canvis arriscats és un bon punt de partida. Les apps amb diners o dades de salut en joc mereixen còpies més freqüents, o una base de dades gestionada amb recuperació en un punt del temps (la capacitat de restaurar a qualsevol moment, no només a l'última còpia).

Pas 2: revisa què fa ja el teu proveïdor

Molts proveïdors de bases de dades gestionades fan còpies automàtiques. Comprova:

Hi ha còpies activades amb el teu pla, i amb quina freqüència s'executen?
Durant quant de temps es conserven?
Pots restaurar a un punt concret del temps, o només a una instantània diària?
Pots descarregar una còpia, o només restaurar-la dins del seu sistema?

Les còpies del proveïdor són útils, però comparteixen un punt únic de fallada amb la base de dades: el compte. Si el compte es tanca, se suspèn o el projecte s'elimina, les còpies poden desaparèixer amb ell. Per això també vols una còpia pròpia.

Pas 3: fes un volcat amb pg_dump

pg_dump exporta una base de dades de Postgres a un fitxer. Llegeix una instantània coherent, així que l'app pot seguir funcionant mentre ho fa.

Una ordre típica, fent servir la cadena de connexió que la teva app ja té en una variable d'entorn:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Què fan les opcions:

--format=custom escriu un fitxer comprimit que pg_restore pot llegir, i et permet restaurar taules individuals més endavant. Fes servir --format=plain si vols un fitxer .sql llegible.
--no-owner omet les ordres de propietat, cosa que simplifica la restauració en una base de dades diferent.
La data del nom del fitxer manté les còpies separades.

La versió de pg_dump ha de ser igual o més nova que la versió de Postgres de la teva base de dades. Un pg_dump més antic pot negar-se a executar-se.

Si construeixes amb IA i no vols tocar la línia d'ordres, pots demanar:

Fes una còpia de seguretat de la base de dades de l'app amb pg_dump en format personalitzat, amb la data d'avui al nom del fitxer. No mostris la cadena de connexió ni cap secret. Digue'm el nom del fitxer i la seva mida quan acabi.

Pas 4: automatitza-ho

Les còpies manuals s'obliden. Automatitza-les amb el que permeti la teva configuració:

Les còpies programades del teu proveïdor de bases de dades, si n'ofereix.
Una tasca programada en un servidor o en un servei de CI que executi pg_dump i pugi el fitxer a l'emmagatzematge.
Un servei de còpies allotjat que es connecta a la teva base de dades.

Sigui quina sigui l'opció, fes que t'avisi quan una còpia falli. Una tasca de còpies que ha fallat en silenci durant tres mesos és la història de terror clàssica.

Pas 5: guarda les còpies en un altre lloc

La regla general es coneix sovint com 3-2-1: tres còpies de les dades, en dos tipus diferents d'emmagatzematge, i una còpia fora del lloc. Per a una app petita, una versió pràctica és:

La base de dades en viu
Les còpies automàtiques del propi proveïdor
Els teus volcats en un emmagatzematge separat, com un bucket d'emmagatzematge d'objectes en un altre compte

A més:

Restringeix l'accés. Una còpia conté les dades de tots els usuaris. Tracta-la com la base de dades en viu.
Defineix una política de retenció. Per exemple, còpies diàries durant dues setmanes i mensuals durant un any. Elimina les antigues de manera intencionada, i recorda que les lleis de privacitat poden obligar-te a esborrar dades personals si ho demana la persona interessada.
Mai no pugis còpies a Git. Un volcat dins d'un repositori és una fuita de dades esperant a passar.

Pas 6: prova una restauració

Una còpia de seguretat només és tan bona com la teva última restauració correcta. Almenys cada pocs mesos, i després de qualsevol canvi en el procés de còpies:

Crea una base de dades nova i buida. Mai no restauris sobre la que està en viu per fer la prova.
Restaura la còpia més recent en ella:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Per a un fitxer .sql en text pla, fes servir psql "$TEST_DATABASE_URL" -f backup.sql.

Comprova que totes les taules existeixen, compara el nombre de files amb la base de dades en viu i mira alguns registres recents.
Connecta una còpia de l'app a aquesta base de dades i inicia sessió, si pots.
Anota quant ha trigat la restauració. Aquest és el teu temps de recuperació real.

Pas 7: fes una còpia abans dels canvis arriscats

Fes una còpia nova just abans de:

Executar una migració de la base de dades que elimini o reanomeni columnes
Importar dades en bloc
Deixar que un agent d'IA faci canvis grans al model de dades
Eliminar registres antics

En una app creada amb IA, l'agent pot canviar l'estructura de les taules com a part d'una funcionalitat. Els punts de control i el control de versions desfan els canvis del codi, però no recuperen files eliminades. Una còpia de trenta segons abans d'un canvi gran és una assegurança barata.

Errors habituals

Suposar que Git o una exportació del codi és una còpia de seguretat. Té el codi, no les dades.
No provar mai una restauració. Moltes còpies resulten buides, incompletes o il·legibles només quan es necessiten.
Guardar les còpies al mateix compte que la base de dades. Un compte compromès o tancat perd les dues coses.
Oblidar els fitxers pujats. La base de dades guarda el camí del fitxer; la imatge en si viu a l'emmagatzematge.
Deixar secrets als scripts de còpia. Llegeix la cadena de connexió d'una variable d'entorn, mai del text de l'script. Consulta com mantenir segures les claus d'API.

Còpies de seguretat i Mythex

Als projectes de Mythex hi pot haver una base de dades Postgres dedicada, i els seus detalls de connexió s'injecten a l'espai de treball i a l'app publicada. La documentació de Mythex no descriu cap funcionalitat de còpia o restauració de la base de dades, així que planifica la teva: demana a l'agent que faci un volcat, descarrega'l i guarda'l en un lloc segur, sobretot abans de canvis grans. Una exportació de projecte (Pro) conté el teu codi, amb els secrets i node_modules deixats fora; no conté les files de la base de dades. Consulta Base de dades i Propietat de les dades a la documentació. Per saber més sobre la base de dades en si, llegeix què és Postgres.

Llista de comprovació de còpies

He decidit quantes dades puc permetre'm perdre i quant de temps puc estar caigut
He revisat quines còpies automàtiques ofereix el meu proveïdor de bases de dades
El meu volcat propi s'executa segons un calendari, i les fallades m'avisen
Les còpies es guarden separades de la base de dades, amb accés restringit
La política de retenció està escrita
Els fitxers pujats també tenen còpia, a més de la base de dades
La restauració s'ha provat en una base de dades buida, i s'han comprovat els nombres de files
Faig una còpia abans de cada canvi arriscat

Preguntes

Amb quina freqüència he de fer una còpia de seguretat de la base de dades de la meva app?

Ajusta-ho a quantes dades pots permetre't perdre. Per a la majoria d'apps petites, una còpia automàtica diària és un mínim sensat, a més d'una còpia manual abans de qualsevol canvi arriscat, com una migració, una importació o una funcionalitat nova important.

Exportar el codi és el mateix que fer una còpia de seguretat de les dades?

No. Una exportació del codi o un repositori de GitHub conté els fitxers de la teva app, no les files de la base de dades. Els teus usuaris, comandes i publicacions viuen a la base de dades i necessiten la seva pròpia còpia de seguretat.

Què és pg_dump?

pg_dump és l'eina de línia d'ordres estàndard que ve amb Postgres per exportar una base de dades a un fitxer. Pot escriure SQL en text pla o un format comprimit personalitzat, i les eines de restauració corresponents són psql per als fitxers SQL i pg_restore per al format personalitzat.

Com sé que la meva còpia de seguretat funciona?

Restaura-la. Carrega la còpia en una base de dades separada i buida, i comprova que les taules existeixen i que el nombre de files i alguns dels registres més recents coincideixen amb les dades en viu. Una còpia que mai has restaurat és una suposició.

On he de guardar les còpies de seguretat de la base de dades?

En un lloc separat de la mateixa base de dades, idealment amb un proveïdor o un compte diferent, i amb l'accés limitat a tu. Les còpies contenen totes les dades dels teus usuaris, així que cal tractar-les amb la mateixa cura que la base de dades en viu.