Lightning-kanal Backup: 41.000 Kanaler, 12 Steg [2026]

En Lightning-node kan miste alt uten at eieren gjør en eneste feil ved selve nøkkelhåndteringen. Disken svikter, en VPS-leverandør bytter maskinvare, eller en oppdatering korrupperer databasen, og plutselig er kanalsaldoen låst fast hos en motpart som ikke svarer. Bitcoin-seeden din beskytter midlene på kjeden (layer 1), men den sier ingenting om hvem som eier hvilken andel av en åpen Lightning-kanal. Det er en helt egen tilstand, og den må sikkerhetskopieres separat. Denne guiden viser deg, steg for steg, hvordan du eksporterer, automatiserer og gjenoppretter kanaldata i LND, og hvordan Core Lightning og Eclair løser det samme problemet på en annen måte.

Guiden er skrevet for deg som allerede kjører, eller er i ferd med å sette opp, en egen Lightning-node, enten på en Raspberry Pi hjemme eller på en VPS. Du trenger ikke være systemadministrator fra før, men du bør være komfortabel med en terminal. Målet er ikke bare å forklare hva en Static Channel Backup er i teorien, men å gi deg et ferdig, testbart oppsett du kan kopiere rett inn i egen drift samme dag.

Hvorfor Lightning-kanaler krever en egen backup-strategi

Lightning Network er i praksis et nettverk av tosidige, off-chain kontoer. Hver kanal representerer en pågående avtale mellom deg og en motpart om hvordan midlene skal fordeles hvis kanalen stenges. Denne avtalen endrer seg for hver betaling som går gjennom kanalen, og den lever kun i nodens lokale database, ikke på blokkjeden. Mister du den databasen uten en gyldig kopi et annet sted, har du ingen automatisk måte å bevise din andel av kanalen på.

Nettverket har vokst kraftig de siste årene, og det gjør konsekvensene av manglende backup større enn før. Ifølge nettverksdata fra mempool.space lå den offentlige kapasiteten i Lightning Network på rundt 4.900 til 6.800 BTC gjennom store deler av 2026, fordelt på mellom 17.000 og 18.400 offentlige noder og rundt 41.000 åpne kanaler. Til sammenligning toppet antall offentlige noder på omtrent 20.700 i 2022, så nedgangen skyldes trolig konsolidering: færre, men større og mer profesjonelt drevne routing-noder tar over for hobbynoder. Det betyr at når en node først mister kanaldata, representerer den ofte en større kapitalsum enn tidligere.

Community-rapporter fra 2025 og 2026 peker på fem gjentakende årsaker til tap: korrupte databasefiler etter diskfeil, gjenoppretting fra en utdatert backup, mislykkede force-close-forsøk som etterlater «zombie-kanaler», forveksling mellom seed-backup og kanal-backup, og feil bruk av gjenopprettingsverktøy. Ingen av disse krever at noen andre gjør noe ondsinnet. De skjer fordi driftere undervurderer hvor mye som kan gå galt på en helt vanlig tirsdag når en VPS restartes uten riktig datamappe kopiert over.

Det som gjør Lightning annerledes enn en vanlig on-chain-lommebok, er at hver kanal er en toveis betalingskontrakt der begge parter til enhver tid har en gyldig, signert «commitment-transaksjon» liggende klar til å publiseres. Hver gang saldoen i kanalen endrer seg, forhandles en ny versjon frem, og den forrige versjonen blir formelt ugyldig samtidig som begge parter bytter en revokeringsnøkkel for den utdaterte tilstanden. Denne mekanismen er selve grunnen til at Lightning er trygt å bruke uten tillit til motparten, men den er også grunnen til at et rent filtap kan koste deg penger: uten oppdatert data vet ikke noden din lenger hvilken versjon av avtalen som er den gyldige.

Hva er en Static Channel Backup, og hva den ikke gjør

Static Channel Backup, forkortet SCB, er LNDs mekanisme for nødsituasjoner. Filen inneholder nok informasjon (kanalpunkt, nøkler og parametere) til at noden kan kontakte motparten på nytt og tvinge frem en stenging av kanalen på kjeden, selv om den lokale kanaldatabasen (channel.db) er helt borte. Det viktigste å forstå er hva SCB ikke er: den er ikke en levende kopi av kanaltilstanden, og den lar deg ikke fortsette å rute betalinger gjennom den samme kanalen etterpå.

Tenk på SCB som en nødluke, ikke som et reservehjul. Når du bruker den til å gjenopprette, forteller du i praksis noden: «jeg har mistet oversikten, hjelp meg å hente ut det som er mitt, og lukk kanalen». Motparten din er fortsatt pålagt av protokollen å samarbeide om en rettferdig avslutning, men selve kanalen som ruteforbindelse er borte etter gjenopprettingen. Skal du fortsette å rute mot den samme peeren, må en ny kanal åpnes fra bunnen av.

En vanlig misforståelse er å tro at SCB-filen er statisk i betydningen «lag den én gang, ferdig». Navnet refererer til at hver individuell oppføring er et øyeblikksbilde, ikke til at filen aldri trenger å oppdateres. Åpner eller stenger du en kanal etter at SCB-filen ble laget, er den filen utdatert for den nye kanalen. LND oppdaterer heldigvis multi-backup-filen automatisk ved kanalendringer i normal drift, men den oppdaterte filen må fortsatt eksporteres og flyttes til et trygt sted utenfor selve noden for at den skal ha noen verdi ved en katastrofe.

Selve formatet på revokerings- og straffemekanismen er beskrevet i Lightning-protokollens offisielle spesifikasjon, kjent som BOLT-dokumentene (Basis of Lightning Technology). Der finner du blant annet hvordan en «justice transaction» fungerer: hvis en motpart likevel forsøker å publisere en gammel, tilbakekalt kanaltilstand, kan den ærlige parten straffe forsøket ved å ta hele kanalsaldoen. Dette er nettopp funksjonen en watchtower overvåker på dine vegne når du selv er offline, men SCB løser et annet problem, nemlig at du i utgangspunktet vet nok til å delta i den samarbeidsvillige eller tvungne avslutningen.

Forutsetninger: dette trenger du før du starter

Guiden forutsetter at du allerede har en fungerende Lightning-node. Sjekk versjonsnummeret ditt før du starter, siden kommandonavn og flagg kan endre seg mellom hovedversjoner. Bruk lnd --version, lightningd --version eller motsvarende for Eclair, og sammenlign mot changelog på prosjektets GitHub-side før du følger stegene nedenfor på et produksjonssystem.

• En Bitcoin full node (bitcoind eller tilsvarende) som er ferdig synkronisert
• LND versjon 0.18 eller nyere, eventuelt Core Lightning versjon 24.x eller nyere, eller Eclair versjon 0.9.x eller nyere
• Root- eller sudo-tilgang til serveren som kjører noden, for å sette opp systemd-tjenester
• En sekundær lagringsplass fysisk adskilt fra noden: USB-minnepenn, NAS, eller en kryptert skylagringstjeneste
• GnuPG (GPG) installert, for å kryptere backup-filer før de flyttes ut av noden
• Grunnleggende kjennskap til kommandolinjen og systemd timers
• Om lag 30-45 minutter til første gjennomkjøring, pluss tid for on-chain-bekreftelser ved en faktisk gjenoppretting

Test aldri en gjenopprettingsprosedyre for første gang på en node med reelle midler. Sett opp et testnet- eller signet-miljø, øv på hele flyten fra eksport til gjenoppretting der, og gjenta den samme sekvensen mot en liten, disponibel kanal på mainnet før du stoler på prosedyren i en reell krise.

Raspberry Pi mot VPS: hvor bør backup-jobben kjøre

De fleste hjemme-noder i Norden kjører etter oppskrifter som RaspiBolt eller MiniBolt, der en Raspberry Pi eller en Intel NUC håndterer både bitcoind og LND lokalt bak eget nettverk. Fordelen er full kontroll og lavt strømforbruk. Ulempen, sett fra et backup-perspektiv, er at all maskinvare på ett sted deler skjebne. Brenner sikringsskapet, eller går det hull i vannrøret over teknisk rom, tar hendelsen med seg både noden og en eventuell lokal backup-kopi samtidig.

Kjører du i stedet på en VPS hos en skyleverandør, er det fysiske risikobildet et annet, men ikke nødvendigvis bedre. En leverandør kan migrere deg til ny maskinvare uten varsel, og du har som regel ikke fysisk tilgang til å hente ut en disk manuelt hvis noe går galt med instansen. I begge tilfeller er konklusjonen den samme: backup-kopien skal aldri hvile på den samme fysiske enheten, i det samme bygget, eller hos den samme leverandøren som selve noden.

En praktisk mellomløsning mange norske nodeoperatører bruker, er å la en billig VPS i en annen region fungere som ren backup-mottaker, uten selv å kjøre noen nodeprogramvare. Den tar kun imot krypterte filer via rsync eller SFTP fra hjemme-noden, og trenger verken åpne porter mot internett for RPC-tilgang eller kjenne til nodens seed. Kompromitteres denne mottaksserveren, sitter en angriper uansett bare igjen med krypterte filer den ikke kan lese uten passfrasen du har lagret et tredje sted.

Steg 1-3: Sett opp og verifiser noden din

Start med å bekrefte at noden faktisk kjører med kanal-backup aktivert, noe som er standardoppførsel i moderne LND-versjoner, men verdt å dobbeltsjekke etter en oppgradering eller en migrering til ny server.

Steg 1: Bekreft nodestatus og versjon

lncli --version
lncli getinfo | grep -E '"version"|"num_active_channels"'

Steg 2: Finn datamappen og standard SCB-plassering

LND lagrer normalt multi-kanal-backup-filen som channel.backup under kjedens datamappe, typisk noe som ~/.lnd/data/chain/bitcoin/mainnet/channel.backup. Filen oppdateres av demonen selv hver gang kanaltilstanden endrer seg, men den ligger fortsatt på samme disk som resten av nodedataene, så den beskytter deg ikke mot totalt diskhavari alene.

ls -la ~/.lnd/data/chain/bitcoin/mainnet/channel.backup
stat --format='Sist endret: %y' ~/.lnd/data/chain/bitcoin/mainnet/channel.backup

Steg 3: Verifiser at eksisterende backup er gyldig

lncli verifychanbackup --multi_file=~/.lnd/data/chain/bitcoin/mainnet/channel.backup

Eksempel på output ved en gyldig fil:

{
    "single_chan_backups": null,
    "multi_chan_backup_valid": true
}

Får du false her, er filen korrupt eller mismatcher gjeldende node-seed, og du bør eksportere en helt ny kopi umiddelbart, som beskrevet i neste steg.

Steg 4-6: Eksporter din første SCB-fil manuelt

Selv om LND vedlikeholder channel.backup automatisk, bør du kjenne kommandoen for manuell eksport, både for å forstå hva som skjer under panseret og for scenarioer der du vil hente ut en frisk kopi rett før en risikabel operasjon som en nodemigrering.

Steg 4: Eksporter alle kanaler til én fil

lncli exportchanbackup --all --output_file /mnt/backup/lnd/channel.backup

Kommandoen skriver en binær multi-backup-fil til stien du angir. Du kan også hente den samme dataen via API-endepunktet ExportAllChannelBackups, noe som er nyttig hvis backup-jobben din kjører fra et separat overvåkingssystem uten CLI-tilgang.

Steg 5: Krypter filen før den forlater noden

gpg --symmetric --cipher-algo AES256 \
  --output /mnt/backup/lnd/channel.backup.gpg \
  /mnt/backup/lnd/channel.backup

shred -u /mnt/backup/lnd/channel.backup

Steg 6: Flytt den krypterte filen til et fysisk adskilt sted

rsync -avz --checksum \
  /mnt/backup/lnd/channel.backup.gpg \
  [email protected]:/volume1/lnd-backups/$(date +%F)-channel.backup.gpg

Passordet du bruker med GPG hører ikke hjemme i samme fysiske lokasjon som noden, og absolutt ikke i samme passordbehandler som andre operative hemmeligheter noden trenger for å starte automatisk. Skriv det ned separat, eller del det opp med en enkel Shamir-ordning hvis flere personer skal kunne gjenopprette noden.

Steg 7-8: Automatiser sikkerhetskopiering med systemd

Manuell eksport fungerer for en test, men i drift glemmer alle å kjøre kommandoen jevnlig. Løsningen er en systemd path-unit som trigger eksport hver gang channel.backup endres, kombinert med en timer som tar en daglig full kopi som sikkerhetsnett.

Steg 7: Skriv backup-skriptet

#!/bin/bash
# /usr/local/bin/lnd-backup.sh
set -euo pipefail

SRC=~/.lnd/data/chain/bitcoin/mainnet/channel.backup
DEST_DIR=/mnt/backup/lnd
STAMP=$(date +%Y%m%d-%H%M%S)

cp "$SRC" "$DEST_DIR/channel-$STAMP.backup"
gpg --batch --yes --symmetric --cipher-algo AES256 \
  --passphrase-file /root/.lnd-backup-pass \
  --output "$DEST_DIR/channel-$STAMP.backup.gpg" \
  "$DEST_DIR/channel-$STAMP.backup"

shred -u "$DEST_DIR/channel-$STAMP.backup"
find "$DEST_DIR" -name '*.backup.gpg' -mtime +30 -delete

logger -t lnd-backup "SCB eksportert og kryptert: channel-$STAMP.backup.gpg"

Steg 8: Sett opp path-unit og timer

# /etc/systemd/system/lnd-backup.path
[Unit]
Description=Trigg backup ved endring i channel.backup

[Path]
PathModified=/root/.lnd/data/chain/bitcoin/mainnet/channel.backup

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/lnd-backup.service
[Unit]
Description=Kjør LND SCB-backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/lnd-backup.sh

# Aktiver
systemctl daemon-reload
systemctl enable --now lnd-backup.path
systemctl status lnd-backup.path

Med denne kombinasjonen får du en frisk, kryptert kopi hver gang en kanal åpnes, lukkes eller på annen måte endrer tilstand, uten at du selv må huske noe som helst i det daglige.

Hold også et øye med diskplassen på selve backup-destinasjonen. Opprydningslinjen i scriptet fjerner kopier eldre enn 30 dager, men på en aktiv routing-node med hyppige kanalendringer kan filmengden likevel vokse raskere enn forventet. Legg inn en enkel overvåking som varsler deg på e-post eller Slack hvis disken passerer en gitt fyllingsgrad, slik at en full disk aldri blir den skjulte årsaken til at en kritisk backup-jobb feiler stille i bakgrunnen.

Steg 9: Lagre backup trygt utenfor noden med 3-2-1-prinsippet

Den klassiske 3-2-1-regelen fra generell IT-drift passer godt for Lightning-backup: hold minst tre kopier, på minst to ulike medietyper, hvorav minst én kopi er fysisk et annet sted enn noden. For en hobbynode kan det bety én kopi på noden selv (den ferske channel.backup), én kryptert kopi på en USB-penn i en safe, og én kryptert kopi hos en betrodd person eller en skytjeneste med ende-til-ende-kryptering.

For en profesjonell routing-node med større kapasitet bør den tredje kopien ligge i en annen geografisk region enn de to andre, slik at en lokal hendelse (brann, strømbrudd, beslag) ikke rammer alle kopiene samtidig. Merk deg at selve GPG-passordet aldri skal ligge lagret sammen med den krypterte filen. Hvis noen får tak i begge deler samtidig, er krypteringen verdiløs.

Sett også en påminnelse om å teste restaurering av backup-filen, ikke bare at den eksisterer. En fil som ikke lar seg dekryptere, eller som feiler verifychanbackup, gir deg falsk trygghet helt frem til den dagen du faktisk trenger den.

Steg 10-11: Gjenopprett kanaler med restorechanbackup

Scenarioet: channel.db er korrupt, eller hele serveren er tapt, men du har en gyldig, nylig SCB-fil og seed-frasen til lommeboken. Slik gjenoppretter du på en frisk installasjon.

Steg 10: Gjenopprett lommeboken fra seed på en ny node

lncli create
# Velg "gjenopprett fra eksisterende seed" i den interaktive dialogen,
# og oppgi de 24 ordene i riktig rekkefølge når du blir bedt om det

Steg 11: Last inn SCB-filen og start gjenopprettingen

gpg --decrypt /mnt/backup/lnd/channel-latest.backup.gpg \
  > /root/.lnd/data/chain/bitcoin/mainnet/channel.backup

lncli restorechanbackup \
  --multi_file=/root/.lnd/data/chain/bitcoin/mainnet/channel.backup

Eksempel på output når kommandoen aksepteres:

{}

Et tomt objekt betyr her at forespørselen ble akseptert, ikke at ingenting skjedde. LND kontakter nå hver motpart som er registrert i backup-filen, i bakgrunnen, og forsøker først en samarbeidsvillig (cooperative) stenging. Bruk lncli pendingchannels for å følge status.

lncli pendingchannels | grep -A5 "pending_force_closing_channels"

Er motparten offline eller usamarbeidsvillig, går LND automatisk videre til en tvungen (force-close) stenging på kjeden, gjennomsyret av kanalens siste kjente commitment-tilstand fra SCB-filen. Midlene dine blir da låst med en tidslås (CSV-delay) i tråd med kanalparameterne, ofte i størrelsesorden noen hundre blokker, før de er fritt disponible.

Legg merke til at SCB-filen kun inneholder statiske parametere, ikke selve den løpende «commitment number»-telleren som brukes til å avgjøre hvilken versjon av kanalen som er nyest. Det er nettopp derfor gjenopprettingen normalt går via en tvungen stenging fremfor en direkte gjenopptakelse av rutingen: noden din har ikke nok informasjon til trygt å garantere at den kjenner den aller siste tilstanden, og faller derfor tilbake på den sikre veien, som er å avslutte kanalen fullt og helt på kjeden.

Steg 12: Full katastrofegjenoppretting med det community-kjente «emergency recovery»-forløpet

Når hele noden er borte, ikke bare kanaldatabasen, kaller mange nodeoperatører den samlede prosessen for «emergency recovery», selv om det ikke er ett enkelt kommandonavn i alle LND-versjoner. I praksis er det den samme sekvensen som over, men kjørt fra bunnen: en helt fersk LND-installasjon, seed-gjenoppretting, og innlasting av den sist kjente SCB-filen.

# 1. Installer LND på ny maskinvare eller VPS
# 2. Start med et blankt datadir og gjenopprett lommeboken fra seed
lnd --lnddir=/root/.lnd

# 3. I et eget terminalvindu, gjennomfør seed- og SCB-gjenoppretting samtidig
lncli create
lncli restorechanbackup --multi_file=/mnt/backup/lnd/channel-latest.backup

# 4. Overvåk force-close-prosessen til alle utestående midler er spendbare
watch -n 60 'lncli walletbalance'

Community-erfaringer fra 2025 og 2026 peker i to retninger her. Der operatører hadde en fersk SCB-fil og fulgte prosedyren riktig, kom on-chain-midlene tilbake i praksis nesten alltid, riktignok med ventetid for tidslåser og med ekstra kjedegebyrer for force-close-transaksjonene. Der SCB-filen manglet eller var flere måneder gammel, var utfallet langt dårligere, og i verste fall helt avhengig av at motparten var samarbeidsvillig av egen fri vilje.

Et gjentakende mønster i operatørrapporter fra 2026 er migreringer mellom VPS-leverandører der driften glemte å kopiere over hele datamappen, ikke bare lommebokfilen. Noden startet pent opp på ny maskinvare, men kjente ikke igjen kanalene fordi bare deler av tilstanden fulgte med. Der driften i tillegg hadde en fersk, ekstern SCB-kopi liggende, var skaden begrenset til noen dagers nedetid og normale kjedegebyrer for force-close. Der den eksterne kopien manglet, endte flere med å skrive av deler av kapitalen som tapt, og omorganiserte driften rundt strengere backup-rutiner i etterkant. Forskjellen mellom de to utfallene lå ikke i hvor stor noden var, men i om en enkel, kjedelig rutine faktisk var på plass før uhellet skjedde.

Core Lightning og Eclair: en annen backup-modell

SCB er et LND-konsept. Core Lightning og Eclair har ikke et direkte tilsvarende enkeltfil-format som lar deg gjenopprette delvis fra et øyeblikksbilde. I stedet er anbefalingen for begge disse implementasjonene å ta jevnlige, fullstendige kopier av hele datamappen, inkludert selve seed-hemmeligheten.

For Core Lightning betyr det databasen lightningd.sqlite3 og filen hsm_secret, som til sammen utgjør nodens fullstendige tilstand. Prosjektets egen dokumentasjon om backup-strategi anbefaler kontinuerlig replikering fremfor sjeldne øyeblikksbilder, nettopp fordi en gammel kopi av kanaltilstanden kan føre til at noden signerer en utdatert, straffbar transaksjon hvis den brukes feil. For Eclair gjelder det samme prinsippet mot databasen eclair.sqlite, dokumentert i prosjektets kildekode og dokumentasjon på GitHub.

Praktisk sett betyr dette at rsync-strategien du allerede har bygget for LND-backupen, med små justeringer, dekker Core Lightning og Eclair også. Bytt bare ut kildefilen fra channel.backup til hele datamappen, og pass på at kopieringen skjer mens filsystemet er i en konsistent tilstand, for eksempel ved å bruke et filsystem-øyeblikksbilde (LVM eller ZFS snapshot) fremfor å kopiere en SQLite-database mens den er i aktiv bruk. En rå filkopi av en database som skrives til samtidig, kan i verste fall gi deg en korrupt backup selv om kopieringsjobben rapporterer suksess.

Nodeprogramvare	Backup-type	Standard filplassering	Gjenopprettingsmetode	Automatisk on-chain gjenoppretting
LND	Static Channel Backup (SCB)	channel.backup i chain-datamappen	lncli restorechanbackup	Ja, via force-close
Core Lightning	Full databasekopi	lightningd.sqlite3 + hsm_secret	Gjenopprett filkopi før oppstart	Nei, krever oppdatert kopi
Eclair	Full databasekopi	eclair.sqlite i datamappen	Gjenopprett filkopi før oppstart	Nei, krever oppdatert kopi
LND (watchtower-klient)	Justisstraff-tilsyn	Ekstern watchtower-node	Automatisk straffetransaksjon	Beskytter mot juks, ikke mot tapt data

Legg merke til den siste raden. En watchtower løser et annet problem enn SCB: den overvåker om en gammel motpart prøver å publisere en utdatert kanaltilstand mens du er offline. Har du full kontroll på egen datamappe, trenger du fortsatt en fungerende backup-rutine i tillegg, watchtoweren erstatter den ikke.

Nettverket i 2026: tallene bak hvorfor backup betyr mer nå

Målt i BTC har den offentlige kapasiteten i Lightning Network svingt betydelig gjennom 2026. Et øyeblikksbilde fra mai 2026, sitert av mempool.space, viste omtrent 4.898 BTC i offentlig kapasitet fordelt på 41.080 kanaler og 17.438 noder. Andre målinger samme år registrerte en topp på rundt 5.637 BTC i april, mens sensommeren 2026 viste tall nærmere 2.600 til 4.900 BTC avhengig av måletidspunkt. Svingningene reflekterer normal kanalåpning og -stenging i et modent nettverk, ikke en samlet nedgang i bruk.

Måltall	Verdi i 2026	Kilde / tidspunkt
Offentlig kapasitet	ca. 4.900 BTC	mempool.space, mai 2026
Offentlige noder	ca. 17.400	mempool.space, 2026
Åpne kanaler	ca. 41.000	mempool.space, mai 2026
Historisk toppkapasitet	ca. 5.637 BTC	Nettverksrapporter, april 2026
Historisk toppantall noder	ca. 20.700	2022, sammenligningsgrunnlag

Nedgangen i node-antall siden 2022-toppen, kombinert med stabil eller voksende kapasitet, peker mot konsolidering: færre operatører drifter større, mer forretningskritiske noder. Det er nøyaktig den typen node der en manglende backup-rutine rammer hardest, fordi kapitalen som står på spill har vokst raskere enn antall hender som passer på den.

For deg som driver en mindre node, betyr disse tallene noe konkret: du deler nettverk med stadig færre, men stadig tyngre motparter. Mister en av dem egen kanaldata samtidig som du mangler oppdatert SCB på din side, blir gjenopprettingen vanskeligere for begge parter, ikke bare for deg. Det er ett argument til for å ikke behandle backup som noe du «tar deg av senere», uansett hvor liten noden din er i dag.

Fem vanlige fallgruver ved kanal-backup

De fleste tapshistoriene i community-rapportene fra 2025 og 2026 følger et lite knippe gjenkjennelige mønstre. Kjenner du dem på forhånd, er de enkle å unngå. Sammenlignet med å gjenopprette en ren on-chain-lommebok, der seed-frasen alene er nok, krever Lightning at du tenker på to separate hemmeligheter og to separate backup-rutiner samtidig.

• Å tro at seed-frasen alene er nok. Seeden gjenoppretter lommebokens on-chain-nøkler, ikke kanaltilstanden. Uten SCB eller en fersk databasekopi er de off-chain-midlene fortsatt utenfor rekkevidde.
• Å bruke en utdatert SCB-fil etter mange nye kanaler. En SCB fra for tre måneder siden kjenner ikke til kanaler åpnet i mellomtiden, og de midlene er ikke dekket av gjenopprettingen i det hele tatt.
• Å flytte node til ny server uten å kopiere hele datamappen. Migrering er den klart hyppigste utløseren av tapshendelser i operatørrapportene, fordi det er lett å glemme én undermappe i farten.
• Å lagre backup og passord på samme sted. En kryptert fil ved siden av passordet i samme passordbehandler gir ingen reell beskyttelse mot noen som får tilgang til kontoen din.
• Å aldri teste gjenoppretting før den trengs. En backup-fil du aldri har forsøkt å lese tilbake, er en antakelse, ikke en sikkerhet.

Feilsøking: åtte problemer og hvordan du løser dem

Selv med en god rutine på plass dukker det opp situasjoner som krever litt detektivarbeid. Her er de mest rapporterte problemene og hvordan du håndterer dem. Sjekk alltid loggene til lnd først (journalctl -u lnd -f på en systemd-drevet installasjon), siden feilmeldingen der som regel peker deg raskere mot riktig rad i tabellen under enn å gjette deg frem.

Problem	Sannsynlig årsak	Løsning
verifychanbackup returnerer false	Filen er korrupt eller stammer fra en annen seed	Eksporter en ny SCB fra en node som faktisk kjører, ikke fra den skadede kopien
restorechanbackup feiler med “seed mismatch”	Feil seed-frase brukt ved gjenoppretting av lommeboken	Bekreft at seeden tilhører samme node som lagde backup-filen, ikke en annen node
Kanaler dukker ikke opp i pendingchannels etter restore	Motparten er offline og har ikke mottatt forespørselen ennå	Vent, og prøv på nytt periodisk, LND fortsetter å forsøke kontakt automatisk
Force-close-transaksjon henger uten bekreftelser	For lav gebyrsats i en periode med høy nettverksbelastning	Bruk CPFP (child-pays-for-parent) på et av dine egne utestående outputs for å øke effektiv gebyrsats
Midler forblir låst lenge etter force-close	CSV-tidslåsen i kanalkontrakten er ikke utløpt ennå	Vent til angitt blokkhøyde, sjekk fremgang med pendingchannels
“Zombie-kanal” som verken lukkes eller ruter	Delvis mislykket force-close eller uenighet om siste tilstand	Kontakt motparten manuelt, eller vent på at protokollens tvisteløsning trer i kraft
GPG-dekryptering feiler ved gjenoppretting	Feil passfrase eller skadet krypteringsfil	Test alltid dekryptering rett etter backup-jobben kjører, ikke først under en krise
Automatisk backup-script kjører ikke	systemd path-unit er ikke aktivert, eller feil filsti i unit-filen	Kjør systemctl status lnd-backup.path og verifiser stien mot faktisk plassering av channel.backup

Avanserte tips for erfarne nodeoperatører

Driver du en større routing-node med mange kanaler, er det verdt å gå et steg lenger enn den grunnleggende rutinen over.

Kombiner SCB-backup med en watchtower-klient for full dekning: SCB beskytter deg mot tap av egne data, watchtoweren beskytter deg mot at en motpart publiserer en gammel, straffbar kanaltilstand mens du er offline. De to mekanismene løser forskjellige trusler, og seriøse routing-noder bruker begge samtidig.

Sett opp overvåking som varsler deg hvis channel.backup ikke har blitt endret på uventet lang tid, gitt normal kanalaktivitet. Et fravær av endringer kan bety at noden ikke lenger klarer å skrive til disk, noe som er et tidlig varsel om et forestående havari heller enn en bekreftelse på at alt er stabilt.

Vurder geografisk spredning for backup-kopiene dine hvis kapitalen på noden overstiger det du er komfortabel med å tape i sin helhet. En kopi i samme datasenter som produksjonsnoden overlever ikke nødvendigvis den samme hendelsen som rammer originalen.

Har du flere noder under samme drift, bygg en sentral logg som viser sist vellykkede backup-tidspunkt for hver enkelt node, ikke bare for den du ser på akkurat nå. Det er lett å bli god på rutinen for hovednoden og glemme at en mindre, eldre node i samme flåte aldri fikk den samme automatiseringen. En enkel dashbord-visning, selv bare en tekstfil som oppdateres av cron og sjekkes manuelt hver morgen, fanger opp dette før det blir et problem.

Til slutt, dokumenter hele gjenopprettingsprosedyren skriftlig, med faktiske kommandoer og filstier, og lagre dokumentet sammen med (men ikke i samme fil som) passordene. Under en reell krise er stresset høyt, og en trinnvis oppskrift du har testet på forhånd sparer minutter som kan bety noe når gebyrmarkedet er anspent.

Følg også utviklingen i selve nodeprogramvaren. LND publiserer endringslogger og sikkerhetsrelaterte oppdateringer fortløpende på det offisielle GitHub-repositoriet, og en ny hovedversjon kan enkelte ganger endre standardoppførsel for hvordan og hvor ofte backup-filen skrives. Sett av tid til å lese endringsloggen før du oppgraderer en produksjonsnode, spesielt hvis oppgraderingen skjer på samme dag som du planlegger andre endringer i infrastrukturen.

Komplett eksempelprosjekt: automatisert backup-pipeline fra start til slutt

Sett sammen blir prosjektet en fullstendig pipeline: LND eksporterer SCB automatisk ved kanalendringer, en systemd path-unit fanger opp endringen og trigger backup-scriptet, scriptet krypterer og eldre kopier ryddes automatisk, og en ekstern rsync-jobb flytter den ferskeste kopien til en NAS eller skytjeneste fysisk adskilt fra noden. Den samlede filstrukturen ser slik ut i praksis.

/usr/local/bin/lnd-backup.sh          # Eksport- og krypteringsscript
/etc/systemd/system/lnd-backup.path   # Trigger ved endring i channel.backup
/etc/systemd/system/lnd-backup.service # Kjører selve scriptet
/mnt/backup/lnd/*.backup.gpg          # Lokale krypterte kopier, 30 dagers historikk
[email protected]:/volume1/lnd-backups/  # Ekstern kopi, off-site

# Verifiser hele kjeden i én kommando
systemctl status lnd-backup.path && \
  ls -la /mnt/backup/lnd/*.gpg | tail -5 && \
  ssh [email protected] 'ls -la /volume1/lnd-backups/ | tail -5'

Med denne pipelinen på plass krever backup ingen manuell handling i det daglige. Den eneste jevnlige oppgaven som gjenstår, er en kvartalsvis test der du faktisk dekrypterer en tilfeldig valgt kopi og kjører verifychanbackup mot den, for å bekrefte at hele kjeden fortsatt fungerer slik den skal.

Øv på gjenoppretting risikofritt på testnet

Den eneste måten å faktisk vite at rutinen din virker, er å kjøre den fra start til slutt uten reelle midler i spill. Signet og testnet gir deg akkurat det handlingsrommet, og en full øvelsesrunde tar sjelden mer enn en ettermiddag.

# Start en LND-instans mot signet i stedet for mainnet
lnd --bitcoin.signet --bitcoin.node=bitcoind \
  --bitcoind.rpcuser=USER --bitcoind.rpcpass=PASS \
  --lnddir=/root/.lnd-signet

# Åpne en liten testkanal mot en offentlig signet-peer
lncli --network=signet openchannel --node_key= --local_amt=100000

# Vent til kanalen er bekreftet, eksporter SCB, og øv gjenopprettingen
lncli --network=signet exportchanbackup --all --output_file /tmp/test-channel.backup
lncli --network=signet verifychanbackup --multi_file=/tmp/test-channel.backup

Gjennomfør deretter en fullstendig gjenoppretting på en helt separat signet-installasjon, akkurat slik du ville gjort på mainnet i en reell krise. Lykkes øvelsen, vet du at både backup-scriptet, den krypterte overføringen og selve kommandosekvensen fungerer sammen, ikke bare hver for seg i isolasjon. Gjenta øvelsen etter enhver større versjonsoppgradering av nodeprogramvaren, siden flagg og filformater sjelden, men noen ganger, endrer seg mellom hovedversjoner.

Sjekkliste før du stoler på oppsettet ditt

Før du erklærer backup-rutinen for produksjonsklar, gå gjennom denne listen én gang til. Hvert punkt bør kunne besvares med et konkret ja, ikke et «sannsynligvis».

• Har du eksportert og verifisert en fersk SCB-fil (eller full datamappe for CLN/Eclair) i dag eller denne uken?
• Ligger minst én kopi fysisk adskilt fra noden, hos en annen leverandør eller på et annet sted enn originalen?
• Er backup-filen kryptert, og ligger passfrasen lagret et helt annet sted enn selve filen?
• Har du faktisk dekryptert og kjørt verifychanbackup mot en tilfeldig valgt kopi i løpet av siste kvartal?
• Kjenner du nøyaktig hvilken kommandosekvens du skal følge under en reell gjenoppretting, uten å måtte lete i dokumentasjon under press?
• Har du testet hele flyten fra eksport til gjenoppretting på testnet eller signet minst én gang?
• Varsler noe deg automatisk hvis backup-jobben feiler eller stopper å kjøre?

Svarer du nei på ett eller flere punkter, er det ikke noe akutt krisetegn, men det er nøyaktig den typen hull som dukker opp i tapshistoriene fra 2025 og 2026. Ta tak i dem nå, mens du har god tid, fremfor midt i en driftshendelse.

Ofte stilte spørsmål

Er en Static Channel Backup det samme som backup av seed-frasen?

Nei. Seed-frasen gjenoppretter on-chain-lommeboken din. SCB-filen gjenoppretter tilgang til off-chain kanaltilstand slik at du kan tvinge frem en stenging og få midlene tilbake på kjeden. Du trenger begge deler for en full gjenoppretting.

Hvor ofte bør jeg eksportere en ny SCB-fil?

I praksis kontinuerlig, ved hjelp av en systemd path-unit som reagerer på endringer i filen automatisk, siden LND selv oppdaterer den ved hver kanalendring. Har du ikke automatisert dette, bør du eksportere manuelt minst hver gang du åpner eller lukker en kanal.

Kan jeg gjenopprette Lightning-kanaler helt uten SCB?

Ikke pålitelig. Uten SCB er du avhengig av at motparten din er samarbeidsvillig og selv initierer en rettferdig stenging. Er motparten uvillig eller selv offline permanent, har du ingen automatisert vei tilbake til midlene.

Fungerer restorechanbackup med Core Lightning eller Eclair?

Nei, kommandoen er spesifikk for LND. Core Lightning og Eclair krever i stedet en fullstendig kopi av datamappen, inkludert seed-hemmeligheten, tatt før hendelsen som skal gjenopprettes fra.

Hvor lang tid tar det å få tilbake midler etter en force-close?

Det varierer med kanalens avtalte CSV-tidslås, ofte flere hundre blokker, i tillegg til vanlig bekreftelsestid for selve force-close-transaksjonen. Regn med at det kan ta fra noen dager til et par uker i en travel gebyrperiode. Er nettverket spesielt overbelastet, kan CPFP på egne utestående utbetalinger korte ned ventetiden noe, men selve tidslåsen kan du ikke omgå uansett gebyrnivå.

Er det trygt å lagre en SCB-fil i skyen?

Ja, forutsatt at filen er kryptert med et sterkt passord før opplasting, og at passordet aldri lagres sammen med filen i samme tjeneste. Ukryptert SCB i skyen bør unngås, siden filen alene gir nok informasjon til å forsøke å stenge kanalene dine.

Hva skjer hvis jeg kjører en gjenopprettingskommando ved en feil, på en node som fortsatt har gyldig kanaldata?

Det kan utløse unødvendige force-close-transaksjoner og ekstra kjedegebyrer, selv om kanalene i utgangspunktet fungerte fint. Kjør alltid verifychanbackup og bekreft nodens faktiske status før du starter en gjenopprettingsprosedyre.

Beskytter en watchtower meg mot tap av kanaldata?

Nei. En watchtower overvåker om en motpart forsøker å publisere en utdatert kanaltilstand mens du er offline, og det er et helt annet problem. Du trenger en fungerende SCB-rutine i tillegg, ikke i stedet for, en watchtower-tjeneste. De to sammen dekker henholdsvis «noen andre jukser» og «jeg mister egne data», og ingen av dem erstatter den andre fullt ut.