Manuella databasexporter låter enkla tills du missar en tabell, skriver över fel fil eller inser att förra veckans ”backup” aldrig faktiskt kördes.
Den här automatiseringen för Postgres GitHub-backup träffar utvecklare först, men dataanalytiker och driftfokuserade grundare känner av den också. Du får en strukturerad, versionshanterad CSV-ögonblicksbild i ett GitHub-repo varje dag, utan att någon behöver sitta och vakta pgAdmin klockan 18.
Nedan är den exakta arbetsflödeslogiken, vad den producerar och var team vanligtvis justerar den så att den matchar repo-struktur och namngivningskonventioner.
Så fungerar automatiseringen
Hela n8n-arbetsflödet, från trigger till slutresultat:
n8n Workflow Template: Postgres till GitHub: versionshanterade CSV-backuper
flowchart LR
subgraph sg0["Scheduled Daily Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Scheduled Daily Trigger", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Fetch Table Records"]
n2@{ icon: "mdi:swap-vertical", form: "rounded", label: "Iterate Batches", pos: "b", h: 48 }
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Transform Script"]
n4@{ icon: "mdi:cog", form: "rounded", label: "Generate CSV File", pos: "b", h: 48 }
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Retrieve Table Catalog"]
n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>List Repo Files GitHub"]
n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/itemLists.svg' width='40' height='40' /></div><br/>Aggregate Repo Filenames"]
n8@{ icon: "mdi:swap-vertical", form: "rounded", label: "Split Single Records", pos: "b", h: 48 }
n9@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Verify Repo File Presence", pos: "b", h: 48 }
n10["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Update GitHub File"]
n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Upload GitHub File"]
n3 --> n1
n1 --> n4
n5 --> n2
n0 --> n6
n2 --> n8
n2 --> n3
n4 --> n2
n10 --> n8
n11 --> n8
n8 --> n9
n7 --> n5
n9 --> n10
n9 --> n11
n6 --> n7
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n9 decision
class n1,n5 database
class n3 code
classDef customIcon fill:none,stroke:none
class n1,n3,n5,n6,n7,n10,n11 customIcon
Problemet: databas-”backuper” som inte är tillförlitliga
De flesta små team misslyckas inte med backuper för att de inte bryr sig. De misslyckas för att processen är störig, lätt att glömma och märkligt skör. Någon exporterar en tabell, laddar ner en CSV, döper om den till ”final-final.csv” och slänger den i en delad mapp som ingen granskar. Sedan ändras schemat. En ny tabell dyker upp. Eller så växer en kritisk tabell och exporten tar längre tid, så den hoppas över ”bara den här gången”. En månad senare behöver du förra tisdagens data och upptäcker att dina snapshots är ofullständiga, inkonsekventa eller saknas helt.
Friktionen byggs på. Här är var det brukar fallera i verkligheten.
- Exporter skalar inte med ditt schema, så nya public-tabeller kommer tyst aldrig med.
- CSV-filer skrivs över eller sprids ut i röriga mappar, vilket gör ”vad ändrades?” jobbigt att svara på.
- Manuella snapshots bjuder in mänskliga misstag, och en enda dålig export kan se ”okej” ut tills du försöker använda den.
- Du tappar tid på rutinjobb i stället för att använda datan, och ärligt talat är det den dyraste delen.
Lösningen: dagliga Postgres-till-GitHub CSV-snapshots
Det här n8n-arbetsflödet körs dagligen och gör varje tabell i ditt Postgres-public-schema till en CSV-fil som lagras i ett GitHub-repository. Först kontrollerar det vad som redan finns i repot, så att det kan undvika dubbletter och avgöra om det ska uppdatera en befintlig tabellexport eller skapa en ny. Sedan hämtar det den aktuella listan över tabeller från Postgres, loopar igenom dem i batchar, extraherar raderna för varje tabell och konverterar datan till en CSV-fil. Slutligen uppdaterar det antingen den matchande filen i GitHub (så att historiken bevaras som commits) eller laddar upp en helt ny CSV om tabellen inte fanns i går.
Arbetsflödet startar med en schematrigger. I mitten jämför det ”tabeller i Postgres” med ”filer i GitHub” och skapar en CSV per tabell. I slutet blir GitHub din dagliga, versionshanterade snapshot-källa som single source of truth.
Vad du får: automatisering vs resultat
| Vad det här arbetsflödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du har 20 public-tabeller och att du exporterar dem manuellt en gång per dag. Även om varje tabell bara tar cirka 5 minuter att köra fråga på, exportera, namnge korrekt och ladda upp, blir det ungefär 100 minuter per dag (och det är en dag när ”inget konstigt händer”). Med det här arbetsflödet är ”arbetet” i princip noll: schematriggern kör automatiskt och sedan får det bara jobba en stund i bakgrunden. De flesta team går från ”någon tappar en timme varje morgon” till ”kolla GitHub om du är nyfiken”.
Det här behöver du
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för egen hosting om du föredrar det (Hostinger fungerar bra)
- Postgres som källa för tabellerna i
public-schemat. - GitHub för att lagra versionshanterade CSV-snapshots i ett repo.
- Postgres-inloggningsuppgifter (skapa en read-only-användare i din databas)
Kunskapsnivå: Nybörjare. Du kopplar Postgres och GitHub i n8n och väljer mål-repo, ingen kodning krävs.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuterskonsultation).
Så fungerar det
Ett dagligt schema drar igång. n8n kör arbetsflödet var 24:e timme, så att du inte är beroende av att någon kommer ihåg exporter efter standup.
GitHub kontrolleras först. Arbetsflödet listar filer i ditt mål-repo och sammanställer filnamnen, vilket gör att det kan avgöra vad som ska uppdateras respektive skapas från grunden.
Postgres-tabeller hittas och exporteras. Det frågar Postgres efter den aktuella listan över tabeller i public-schemat, loopar sedan igenom dem i hanterbara batchar, hämtar rader från varje tabell och konverterar resultatet till en CSV-fil.
Filer uppdateras eller laddas upp. Om en CSV redan finns för tabellen uppdaterar arbetsflödet GitHub-filen (skapar en commit). Om det är en ny tabell laddar det upp en ny fil till repot.
Du kan enkelt justera schema, namngivningsregler eller repo-mappstruktur så att det matchar era interna konventioner. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera den schemalagda triggern
Ställ in arbetsflödet så att det körs automatiskt enligt ett dagligt schema.
- Lägg till och öppna Scheduled Daily Trigger.
- Ställ in Rule till ett intervall med hours och hoursInterval satt till
24.
Steg 2: anslut GitHub och katalogisera befintliga filer
Hämta filnamnen i det befintliga repositoriet så att arbetsflödet kan avgöra om det ska uppdatera eller ladda upp backuper.
- Öppna List Repo Files GitHub och ställ in Owner till
useroch Repository tillgithub-repo. - Låt Resource vara satt till
fileoch Operation vara satt tilllist. - Lämna File Path som
=för att lista filer i root-katalogen. - Autentiseringsuppgift krävs: Anslut era githubOAuth2Api-uppgifter i List Repo Files GitHub.
- Öppna Aggregate Repo Filenames och ställ in Operation till
aggregateItemsmed Fields To Aggregate satt tillname.
Steg 3: anslut Postgres och läs in tabellkatalogen
Fråga er databas för att lista alla publika tabeller som ska säkerhetskopieras.
- Öppna Retrieve Table Catalog och ställ in Schema till
information_schema. - Ställ in Table till
tablesoch lägg till ett Where-filter med columntable_schemaoch valuepublic. - Autentiseringsuppgift krävs: Anslut era postgres-uppgifter i Retrieve Table Catalog.
- Öppna Iterate Batches (första instansen) för att bearbeta katalogen i batcher.
Steg 4: hämta tabellrader och skapa CSV-filer
Loopa igenom varje tabell, hämta rader och konvertera dem till CSV.
- Öppna Transform Script och låt JavaScript Code vara satt till
return $input.all();. - Öppna Fetch Table Records och ställ in Operation till
selectmed Return All aktiverat. - Ställ in Table till uttrycket
{{ $json.table_name }}och Schema tillpublic. - Autentiseringsuppgift krävs: Anslut era postgres-uppgifter i Fetch Table Records.
- Öppna Generate CSV File och ställ in Binary Property Name till
=data. - Ställ in File Name till
{{ $('Retrieve Table Catalog').item.json.table_name }}så att varje CSV namnges efter sin tabell. - Koppla Generate CSV File till Iterate Batches enligt arbetsflödet.
public korrekt.Steg 5: dela upp poster och routa till GitHub-uppdatering eller uppladdning
Bearbeta en CSV i taget och avgör om en befintlig fil ska uppdateras eller om en ny ska laddas upp.
- Öppna Split Single Records och ställ in Batch Size till
1. - Öppna Verify Repo File Presence och ställ in strängvillkoret till:
- Value 1:
{{ $node['Aggregate Repo Filenames'].json.name }} - Value 2:
{{ $binary.data.fileName }} - Operation:
contains - Observera att Verify Repo File Presence skickar vidare till både Update GitHub File och Upload GitHub File beroende på villkoret.
Steg 6: konfigurera åtgärderna för GitHub-uppdatering och uppladdning
Skriv CSV-backuper till ert GitHub-repo med unika commit-meddelanden.
- Öppna Update GitHub File och ställ in Resource till
fileoch Operation tilledit. - Ställ in File Path till
{{ $binary.data.fileName }}och aktivera Binary Data. - Ställ in Commit Message till
=backup-{{ $now.toMillis() }}. - Autentiseringsuppgift krävs: Anslut era githubOAuth2Api-uppgifter i Update GitHub File.
- Öppna Upload GitHub File och ställ in Resource till
filemed Binary Data aktiverat. - Ställ in File Path till
{{ $binary.data.fileName }}. - Ställ in Commit Message till
=backup-{{ $node['Set commit date'].json.commitDate }}. - Autentiseringsuppgift krävs: Anslut era githubOAuth2Api-uppgifter i Upload GitHub File.
{{ $node['Set commit date'].json.commitDate }} refererar till en nod som inte finns i det här arbetsflödet. Ersätt det med ett giltigt uttryck (till exempel {{ $now.toMillis() }}) eller lägg till den saknade noden innan ni kör.Steg 7: testa och aktivera ert arbetsflöde
Verifiera backupflödet end-to-end och aktivera automationen.
- Klicka på Execute Workflow för att köra ett manuellt test från Scheduled Daily Trigger.
- Bekräfta att List Repo Files GitHub returnerar filnamn och att Retrieve Table Catalog returnerar publika tabeller.
- Verifiera att Generate CSV File ger ut en binär fil med namn efter varje tabell.
- Kontrollera att Verify Repo File Presence routar filer till Update GitHub File eller Upload GitHub File korrekt.
- Öppna ert GitHub-repo och bekräfta nya eller uppdaterade CSV-filer med förväntat commit-meddelande.
- Slå på arbetsflödet Active för att aktivera dagliga backuper.
Vanliga fallgropar
- GitHub-inloggningar kan löpa ut eller kräva specifika behörigheter. Om något slutar fungera, kontrollera först din GitHub-inloggning i n8n och repo-åtkomstens scope.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du att redigera output för alltid.
Vanliga frågor
Cirka 30 minuter om du redan har åtkomst till Postgres och GitHub på plats.
Nej. Du kopplar konton och justerar ett par konfigurationsfält i n8n.
Ja. n8n har ett gratis alternativ för egen hosting och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in GitHub- och Postgres-användning (oftast 0 USD för normal API-åtkomst).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen hosting på en VPS. För egen hosting är Hostinger VPS prisvärt och klarar n8n bra. Egen hosting ger obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det är en vanlig justering. Du kan ändra Postgres-katalogfrågan i noden ”Retrieve Table Catalog” för att rikta in dig på ett annat schema, och du kan justera destinationssökvägen i noderna ”Upload GitHub File” och ”Update GitHub File” för att skriva till en undermapp som /snapshots/public/. Många team ändrar också noden ”Transform Script” för att standardisera filnamn (gemener, understreck) och för att hoppa över tabeller de inte vill exportera.
Oftast är det ett problem med OAuth-scope eller repo-behörigheter. Återanslut GitHub-inloggningen i n8n, bekräfta att du gav åtkomst till mål-repot och kör sedan noden ”List Repo Files GitHub” igen för att verifiera att den kan läsa innehållet. Om uppdateringar misslyckas men listning fungerar, kontrollera om arbetsflödet försöker skriva till en skyddad branch. Rate limits kan också vara en faktor om du exporterar många tabeller samtidigt, så batchning hjälper.
Dussintals är normalt, och hundratals kan fungera om din databas och ditt repo är dimensionerade för det.
Ofta, ja, eftersom det här jobbet är mer än en enkel tvåstegs-zap. n8n hanterar loopar över tabeller, grenlogik och filuppdateringar på ett snyggt sätt, och du kan köra egen hosting för obegränsade körningar. Zapier och Make kan lösa delar av det, men du hamnar ofta i att jonglera iterators, filtransformering och prissättningsgränser. Om ni redan jobbar i GitHub och bryr er om versionshistorik är n8n ett praktiskt val. Prata med en automationsexpert om du är osäker på vad som passar.
När detta väl rullar blir GitHub i det tysta ert dagliga snapshot-bibliotek. Sätt upp det, låt det committa och lägg tiden på arbete som faktiskt tar er framåt.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.