Off-site och återställning

Off-site-kopior väntar efter en ombyggnad

När steg 4 återbygger poster utan de gamla inställningarna pausar off-site-replikeringen för de domänerna tills standardplaceringen bekräftas. Se Placering per objekt.

Lokala säkerhetskopior skyddar dig mot en förlorad container eller en dålig uppdatering. Off-site-replikering och ett testat återställningskit skyddar dig mot hela boxen, ransomware eller en brand. Den här sidan täcker att replikera off-site, att göra den kopian manipuleringssäker, att bevisa att du kan återställa, och att återhämta dig när BombVault självt är borta.

Off-site-replikering

Behåll den snabba lokala säkerhetskopian och lägg till en eller flera off-site-repliker. Ange ett repo per domän på sidan Inställningar, Extern. BombVault replikerar nya ögonblicksbilder dit med restic copy på best-effort-basis, så att en off-site-hicka aldrig misslyckar den lokala säkerhetskopian. I den här formen förblir det lokala repot primärt och off-site-repot är en replik, men en domäns primära repo behöver inte alls vara lokalt; se Fjärranslutna primära arkiv nedan för att säkerhetskopiera direkt till S3, en rest-server osv. i stället för att replikera dit.

• Flera off-site-mål per domän. Varje domän (containrar, VM:ar, flash, config, filuppsättningar och ZFS-datauppsättningar) kan replikera till flera off-site-mål samtidigt, inte bara ett, så att du kan hålla, till exempel, en rest-server på en väns box och en S3-bucket parallellt. Lägg till extra mål under Inställningar, Extern, var och en med sitt eget repository, S3-lagringsklass, append-only-flagga, retention och tillväxtbudget. En befintlig enskild off-site-uppsättning förs över orörd som det första målet, och varje mål i en domän replikeras enligt den domänens off-site-schema.
• Off-site-schema per domän (redigerat tillsammans med alla andra scheman under Inställningar, Scheman): lämna det tomt för att replikera efter varje lokal säkerhetskopiering, eller sätt en kadens (till exempel weekly Sun 03:00) för att skicka off-site mer sällan än du säkerhetskopierar lokalt. En Replikera nu-knapp täcker körningar på begäran.
• Off-site-retention finns under Inställningar, Bevarande så att du kan behålla off-site-kopior längre som ett arkiv. Lämna policyn helt-noll för att aldrig autotrimma off-site-ögonblicksbilder.
• Bandbreddsgränser (Inställningar, Extern) begränsar restics uppladdnings-/nedladdningshastighet så att replikering inte mättar din WAN.
• En replikeringsindikator visar vilken domän som replikeras medan det pågår (på dess sida och Översikten). Det är en aktiv indikator, inte en procentstapel, eftersom restic copy inte exponerar något maskinläsbart förlopp.

Återställ från vilken plats som helst

Varje container, VM, filuppsättning, flashen och app-konfigurationen listar sina säkerhetskopior som en enda tidslinje över alla platser en kopia ligger på. En säkerhetskopia kopierad till B2 dyker upp en gång, märkt med varje plats som har den. En återställning tar den första platsen den kan nå, med start i det arkiv objektet skrivs till, och du kan välja en annan plats per rad. Off-site-platser läses bara när du öppnar dem. Att radera på en plats kontrollerar först de andra och säger om det var den sista kopian.

Mål

Inställningar, Extern börjar med Mål: de platser dit off-site-kopiorna går, uppsatta en gång för alla domäner. Ett mål dyker sedan upp som en knapp i raden Placering för varje domän och objekt. Första gången det kryssas i för en domän skapar BombVault domänens arkiv i en mapp under det, till exempel rclone:onedrive:BombVault/containers. Flash, Auto-säkerhetskopia och ZFS-datauppsättningar har ingen rad Placering, så deras off-site-avsnitt erbjuder i stället Lägg till från och målets namn.

Lägg till mål öppnar en guide i fem steg:

1. Vart ska säkerhetskopiorna ta vägen? Varje tjänst visas med sin logotyp, i fyra grupper: lagringstjänster med S3-bucketar (Backblaze B2, Wasabi, Cloudflare R2, Hetzner Object Storage, Amazon S3 och fler), din egen S3-server (Garage, SeaweedFS, RustFS, Silo, Ceph, JuiceFS, Versity S3 Gateway), din egen server och dina resurser (rest-server, Hetzner Storage Box, SFTP, SMB, WebDAV, en monterad sökväg) och molnlagring (OneDrive, Google Drive, Dropbox, pCloud, Nextcloud och resten som rclone stöder). Varje tjänst anger hur väl den lämpar sig för säkerhetskopior: molndiskar saktar ner vid många förfrågningar, så den första säkerhetskopian och rensningen tar längre tid där.
2. Logga in på den valda tjänsten. Fälten beror på tjänsten: en åtkomstnyckel för S3, användare och lösenord för WebDAV och SMB, ett appspecifikt lösenord där tvåstegsinloggning blockerar det vanliga, BombVaults publika SSH-nyckel för SFTP och Storage Box, eller en token för tjänster som loggar in via webbläsaren. För dem visar guiden ett rclone authorize-kommando som körs på en dator med webbläsare; den token det skriver ut klistras in i fältet. Testa anslutning kontrollerar inloggningen innan något sparas.
3. Välj en mapp. Guiden listar mapparna på målet, med Ny mapp för att skapa en och med ledigt utrymme där tjänsten rapporterar det. En tom mapp är säkrast.
4. Skydd mot radering. Guiden säger rakt ut vad tjänsten kan. En rest-server i append-only-läge vägrar radering, och manipulationstestet kontrollerar det. En S3-bucket kan behålla gamla versioner med versionshantering och objektlås, vilket BombVault ännu inte kan kontrollera. En molndisk kan inte vägra radering alls: den som tar sig in på servern tar sig också in i den kopian. Slå bara på Oföränderlig (append-only) där andra sidan verkligen vägrar radering; BombVault rensar då aldrig där.
5. För nödläge. Återställningskitet listar varje mål med arkivet för varje domän under det. Inloggningen kommer tillbaka med BombVaults inställningssäkerhetskopia; på en ny installation utan den sätter du upp målet igen på samma plats.

S3-tjänster körs genom restics egen S3-backend, vilket gör att lagringsklass och objektlås kan tillämpas. Alla andra tjänster körs genom den rclone som BombVault levererar, och dess remote syns sedan i rclone-konfigurationen under Inställningar, Molnåtkomst. En export av inställningarna innehåller målen; med uppgifter inkluderade innehåller den även deras inloggning.

En mottagarserver som en annan instans i din grupp kör visas i guiden under Från din grupp; se Mottagarserver.

Ett off-site-mål för en domän som skapats från ett mål tar över det målets namn, plats, uppgifter, lagringsklass och omkopplaren för oföränderlighet. Dess retention, komprimering och tillväxtbudget förblir per domän, och dess plats kan inte flyttas eftersom domänens arkiv ligger där. Lägg till ett mål bara för den här domänen under varje domän tar fortfarande en handskriven arkiv-URL.

Ett handskrivet mål vars arkiv ligger i en mapp under ett mål kan gå med i det. Målet listar sådana mål under Ligger redan under det här målet, och Ta över hänger upp ett på det. Det handskrivna målet behåller sitt arkiv, sina snapshots, sin retention och sin placering och tar över målets namn, uppgifter, lagringsklass och omkopplaren för oföränderlighet. BombVault kontrollerar först att målets inloggning öppnar arkivet och vägrar lägga ett append-only-mål under ett mål som inte är append-only. Om du tar över en domäns primära mål töms domänens off-site-fält.

Placering per objekt

Varje kort för container, VM och filuppsättning har en rad Placering med knappar: Lokal och en knapp per off-site-mål för domänen, följt av de mål som domänen ännu inte har något mål under. Tända knappar får objektets säkerhetskopior.

• Med Lokal tänd skrivs objektet till arkivet som visas under Sparad på och kopieras till varje annat tänt mål. Släck ett mål och det får inget nytt från det här objektet. Enbart Lokal kopierar ingenstans, vilket passar data som redan har en andra kopia, till exempel en resurs som ligger på en NAS.
• Med Lokal släckt skrivs objektet direkt till det direkta arkivet för det första tända målet och kopieras därifrån till de andra tända målen. Första gången skapar en dialog det direkta arkivet.
• En målknapp skapar domänens mål under det målet och tänder det bara för det här objektet. Varje annat objekt börjar utan kopia där.
• En knapp förblir alltid tänd, eftersom en säkerhetskopia behöver någonstans att ta vägen. Vill du lämna något utanför säkerhetskopiorna, utesluter du det.

Platsen är fast från objektets första säkerhetskopiering, eftersom BombVault aldrig flyttar säkerhetskopior mellan arkiv. Kopiorna kan ändras när som helst. Ett mål som inte längre får ett objekt behåller de kopior det har och trimmar dem till sin egen retention vid domänens nästa off-site-körning; Radera hos B2 på kortet tar bort dem direkt. När några av de kopiorna inte finns någon annanstans listar bekräftelsen dem efter datum och ber om objektets namn. Från append-only-mål går det inte att radera.

Under raden berättar kortet vart objektet går och vad som faktiskt finns där: hur många platser som har det, när varje mål senast sågs, och om 3-2-1 är uppfyllt. En plats är servern med originaldata, varje off-site-mål och varje arkiv märkt Utanför lokalerna. BombVault kontrollerar kopior och platser; det kontrollerar inte ”två medier”-delen av 3-2-1.

Standardplaceringar

Inställningar, Lagring, Standardplaceringar har en rad per domän med samma knappar. Kopiorna gäller genast för varje objekt utan eget val, och för projektmapparna i Compose-stackar. Platsen gäller för ett nytt objekt vid dess första säkerhetskopiering; att ändra den flyttar inga säkerhetskopior. Innan du sparar namnger raden varje mål som vinner eller förlorar objekt och hur många ögonblicksbilder det innebär. Tillämpa på objekt utan säkerhetskopior sätter tillbaka varje objekt som ännu inte har en säkerhetskopia till standarden.

Ett nytt off-site-mål tar emot varje objekt som inte är satt till Lokal. Dialogen som lägger till det säger hur många objekt det är och, där det är känt, hur mycket historik det motsvarar, och erbjuder att lämna ute objekt som redan är uteslutna från andra mål.

Direkta arkiv

Att stänga av Lokal för ett objekt, så att ett mål utan direkt arkiv blir dess hem, öppnar en dialog med en föreslagen plats intill målet, till exempel s3:https://s3.eu-central-003.backblazeb2.com/bucket/containers-direct, och ett anslutningstest som inte skapar något. Skapa och använd skapar arkivet och pekar objektet mot det. Ett direkt arkiv tar över målets nyckel, lagringsklass, gränser, append-only-inställning och retention, och ändras med dem; kortet Arkiv visar det skrivskyddat. När en ny nyckel för målet inte kan öppna det behåller det direkta arkivet den nyckel det har, och sparningen säger det. Ett objekt på ett direkt arkiv kopieras därifrån till de andra tända målen, aldrig till det mål som arkivet tillhör. Dess ögonblicksbilder bär taggen bv:direct, och varje annan retention-passering behåller dem, så ett direkt arkiv som förlorat kopplingen till sitt mål åldras aldrig efter de lokala reglerna. B2 nås via sin S3-slutpunkt, med nyckel-ID och programnyckel angivna som S3-uppgifter; en nyckel som är begränsad till målets egen mapp når inte mappen bredvid den, så begränsa i stället nyckeln till mappen ovanför målet.

Utanför lokalerna

Ett namngivet arkiv kan märkas Utanför lokalerna på kortet Arkiv. Fjärrarkiv börjar märkta; stäng av det för en rest-server i samma byggnad. Märkningen räknas bara för platser och 3-2-1 på korten. Den ändrar ingen kopia.

Efter en ombyggnad

Kopieringsval lever i BombVaults egna inställningar. Efter en ombyggnad via Identifiera säkerhetskopior utan en återställd /config är de borta, och att kopiera allt skulle skicka objekten du hade lämnat ute till B2 igen. Off-site-replikering för varje ombyggd domän pausar därför. Översikten visar det i gult, och Standardplaceringar erbjuder Bekräfta standard med en förhandsgranskning av vad nästa körning kopierar och namnen i säkerhetskopiorna som saknar en post, vilka du kan lämna ute där. Endast bekräftelsen avslutar pausen; att importera en inställningsfil tar tillbaka regler och standarder men avslutar den inte.

Fjärranslutna primära arkiv

En domäns säkerhetskopieringssökväg (Inställningar, Lagring) är inte begränsad till en lokal mapp: rikta den direkt mot ett restic-fjärrarkiv (s3:..., rest:http://värd:8000/arkiv, sftp:användare@värd:/arkiv, rclone:fjärr:bucket/sökväg) så säkerhetskopierar BombVault dit direkt, utan separat lokal kopia och utan replikeringssteg. Det är en verkligt annan form än off-site-replikeringen ovan: där är det lokala arkivet primärt och off-site-arkivet ett arkiv av det efter bästa förmåga; här är fjärrarkivet det primära, och det är den enda kopian så länge du inte också ställer in off-site-replikering (eller ett andra fjärrarkiv) för den domänen.

Vart och ett av de sex sökvägsfälten (Containers, VMs, Flash, Auto-säkerhetskopia, Mappar, ZFS-datauppsättningar) har en omkopplare Lokal / Fjärran alldeles intill:

• Lokal visar den vanliga mappbläddraren.
• Fjärran byter ut den mot ett enkelt URL-fält, plus en knapp som öppnar samma dialog för anslutningstest och inloggningsuppgifter som off-site-destinationer använder, fast inställd för det här primära arkivet. Därifrån får du:
  • Ett anslutningstest mot den verkliga sökvägen, innan du förlitar dig på den.
  • Bandbreddsgränser (uppladdning och nedladdning) så att en schemalagd säkerhetskopiering till ett fjärrprimärt arkiv inte mättar din WAN-länk: samma restic-flaggor --limit-upload och --limit-download som off-site-replikeringen använder, nu tillämpade på själva säkerhetskopieringen.
  • Append-only-skydd (oföränderlighet), verifierat med samma aktiva manipulationstest (en riktig DELETE-sond mot andra sidan) som off-site-destinationer får. Med det påslaget vägrar BombVault att själv gallra arkivet: eftersom ingen separat lokal kopia står bakom, får inloggningsuppgifterna på den här maskinen inte kunna radera säkerhetskopians enda kopia.
  • Ett larm för tillväxtbudgeten, hämtat ur samma trend för arkivets storlek som Lagringskortet redan följer.

Inget av detta är obligatoriskt: en handskriven fjärrsökväg utan sparade säkerhetsinställningar säkerhetskopierar precis som förut (obegränsad bandbredd, gallringsbar, inget budgetlarm). Säkerhetsdialogen finns där för när du vill ha samma skydd som en off-site-kopia får, utan att behöva skapa en off-site-destination bara för det.

Moln- och REST-uppgifter delas

Ett fjärrprimärt arkiv autentiserar med samma S3-/REST-uppgifter som ställts in under Inställningar, Molnåtkomst, Delade molnautentiseringsuppgifter. Det finns ingen separat uppgiftslagring för primära arkiv.

SMB och WebDAV utan värdmontering

Inställningar, Molnåtkomst, rclone har ett formulär för en Windows- eller Samba-resurs och för en WebDAV-server (Nextcloud, ownCloud, SharePoint eller någon annan). Fyll i ett kort namn, värden och resursen (SMB) eller URL:en och servertypen (WebDAV), användaren och lösenordet, så skriver BombVault rclone-avsnittet åt dig. rclone döljer själv lösenordet innan det sparas; lägger du till en destination med ett namn som redan finns ersätter den det avsnittet i stället för att lägga till ett andra.

Formuläret svarar med den färdiga platsen, till exempel rclone:nas:backups. Lägg in den i en säkerhetskopieringssökväg eller en off-site-destination och lägg till en undermapp om du vill ha en (rclone:nas:backups/bombvault). Resursen är det första ledet i sökvägen, inte en del av namnet.

Det här är en bättre väg än att montera resursen på Unraid: restic avråder från att ha ett repository på en monterad CIFS-resurs, och här monteras ingenting. NFS finns inte i formuläret eftersom varken restic eller rclone har en NFS-backend; för NFS monterar du exporten på värden och pekar en säkerhetskopieringssökväg mot den.

Oföränderligt (append-only) off-site

Flagga ett off-site-repo append-only så att ransomware, eller en komprometterad värd, inte kan radera eller skriva om dina säkerhetskopior. Den bortre sidan (en restic/rest-server som körs i --append-only-läge) upprätthåller det. BombVault verifierar det bara och visar aldrig grönt enbart på ett konfigurationspåstående.

Guiden guidad off-site-uppsättning lotsar dig från val av backend (rest-server / rclone / S3) genom ett färdigt-att-klistra-in rest-server-deploy-utdrag, ett anslutningstest, den oföränderliga växeln (som kör manipulationstestet omedelbart) och en retention-strategi, så att append-only off-site är nåbar utan att handredigera konfigurationer.

En lyckad radering under /locks/ är förväntad

Append-only betyder inte att ingenting längre kan raderas. restic måste ta och släppa sina egna lås, så /locks/ förblir avsiktligt skrivbar och raderbar. Ögonblicksbilder och datan bakom dem, alltså precis det som utpressningsprogram skulle gå efter, går inte att ta bort. Testar du motparten själv är en radering som lyckas under /locks/ korrekt beteende och inte ett hål i skyddet.

Oföränderliga repos rensas aldrig från den här boxen

Ett oföränderligt off-site rensar avsiktligt aldrig gamla ögonblicksbilder. Sätt ett tillväxtbudget-alarm för det så att du varnas innan repo-storleken skenar iväg.

Manipulationstest

BombVault bevisar regelbundet append-only-garantin genom att faktiskt försöka en radering mot off-site-repot, riktad mot ett obefintligt objekt:

• Nekad betyder skyddad.
• Accepterad betyder inte skyddad.
• Ett obestämt resultat (server onåbar, autentiseringsfel) vänder aldrig det lagrade utslaget.

En verklig skyddad-till-oskyddad-vändning avfyrar ett enda larm.

DR-övningar

BombVault erbjuder två nivåer av bevis på att dina säkerhetskopior faktiskt går att återställa, inte bara finns.

• Återställningsverifieringsövningar (lokala). BombVault kör regelbundet restic check --read-data-subset (avgränsad, aldrig en diskfyllande fullständig återställning) och visar en Verifierat återställbar-märkning per domän. Kadensen finns under Inställningar, Scheman; märkningen under Inställningar, Integritet.
• DR-övningar (off-site). BombVault återställer ett verkligt mål från off-site-repot till en engångssandlåda, verifierar det fil-för-fil och byte-för-byte, och städar sedan upp. Detta bevisar att du kan återhämta dig från off-site, inte bara att repot svarar.

Poängkortet för ransomware-skydd på Översikten rullar upp detta i en grön / gul / röd hållning per domän, med en åldersstämplad checklista (off-site konfigurerat, append-only verifierat, replikering aktuell, återställningsövning godkänd, kryptering på, rensningsstrategi satt). Varje röd rad djuplänkar till åtgärden, och kortet blir grönt endast på verifierade fakta.

Parkoppling av instanser

Mottagare, Hämtning-källor, Instanser-sidan och Mesh-off-site pratar alla med en annan BombVault. De gör det som medlemmar i en och samma parkopplingsgrupp, och en instans går med i gruppen med tolv ord.

På den första instansen, öppna Inställningar → Parkoppling och klicka på Skapa fras i parkopplingskorten. Tolv ord dyker upp i ett fönster med en Kopiera-knapp. På varje annan instans, öppna samma plats, klicka på Ange fras och klistra in eller skriv in orden, eller klicka på Klistra in i det fönstret. Ett ord som inte finns i listan namnges med sin plats redan medan du skriver, och det sista ordet bär en kontrollsumma, så ett feltippat eller omkastat ord fångas innan något parkopplas. Skapa frasen på bara en instans: två instanser som båda skapar en fras bildar två separata grupper. Om ingen dyker upp inom en minut erbjuder fliken två utvägar: visa orden igen för att skriva in dem där borta, eller skriv in den andra instansens ord och gå med i dess grupp i ett steg. Parkoppling fungerar utan inloggningslösenord också, men ange ett: utan det kan alla som kan öppna det här webbgränssnittet läsa orden och via gruppen få tag i restic-lösenordet för varje instans i den. Parkopplingskortet säger det tills ett lösenord är angett. Med ett lösenord frågar en förnyad visning av frasen efter det. Lämna gruppen tar en instans ur den igen.

Den som känner till orden kan gå med i gruppen, så behandla dem som ett lösenord.

Hur medlemmar når varandra. Varje instans lär sig sin egen adress på nätverket från din webbläsare så snart du loggar in, den visas i reläkortet som Den här instansen på ditt nätverk; rätta den där om en reverse proxy eller en ovanlig port ligger framför. I samma nätverk kungör medlemmarna den adressen via multicast och pratar direkt med varandra, och där multicast inte kan ta sig över ett containernätverk, som Dockers standard-bridge-nätverk, söker en instans i stället igenom sitt eget subnät efter de andra med ett signerat anrop som bara en gruppmedlem kan svara på, så parkopplingen ändå blir klar på några sekunder utan relä. Dyker inget upp tar Hittar du den inte? under parkopplingskortet emot en adress för hand, för ett annat subnät eller en icke-standardport. Instanser i olika nätverk går via ett relä, valt på samma flik:

• Projektrelä (standard): parleyport.halleluja.design, samma relä som KnightLoader använder. Inget att ställa in.
• Eget relä: containern ParleyPort från Unraid Community Apps, eller en av dina instanser som redan är nåbar utifrån med Fungera som relä påslaget. Den instansen svarar då på /relay/connect på sin egen adress, bakom den reverse proxy och det certifikat den redan har, och släpper bara in din grupp. Ange reläets adress på varje instans som ska använda det.
• Inget relä: medlemmar hittar varandra automatiskt i samma nätverk, och ingen annanstans.

Vad reläet ser. Varje anrop mellan medlemmar är förseglat med AES-256-GCM under en nyckel härledd ur de tolv orden, och den nyckeln lämnar aldrig dina instanser. Reläet lär sig en hash som grupperar anslutningarna, vilken instans ett meddelande är till, hur stort det är och när det passerar. Ett direkt anrop i det lokala nätverket är förseglat på samma sätt och även signerat, så inget beror på det självsignerade certifikat en instans visar upp.

Vad som färdas över gruppen. Poängkorten på Instanser-sidan, en begäran att kontrollera en domän just nu, erbjudanden om extern lagring från Mesh, och det en mottagare eller en Hämtning-källa behöver: den andra instansens repository-platser och dess restic-lösenord. Säkerhetskopieringsdata gör det aldrig; den går alltid direkt till restic-backendarna. Inte heller APP_KEY: restic-lösenordet öppnar bara den instansens repositorier och inget annat, inte dess sparade hemligheter, sessioner eller återställningskoder.

Poster från innan parkoppling. Instanser som lagts till med en flotta-token, och mottagare och Hämtning-källor som satts upp med den andra instansens APP_KEY, finns kvar efter uppdateringen och märks Parkoppla igen. Mottagare och Hämtning-källor fortsätter att fungera: vid sin första start ersätter BombVault varje sparad APP_KEY med det restic-lösenord som härletts ur den. Parkoppla båda instanserna, redigera sedan posten och välj dess instans. En sådan instans tar över sitt gamla kort så snart en instans med samma namn dyker upp i gruppen.

Den enda plats som fortfarande tar emot en APP_KEY för hand är Återställ från ett annat BombVault-repo, för fallet att den andra instansen är borta och inte kan svara i en grupp.

Mottagarpanel (den mottagande sidan)

Den mottagande sidan, bevakad skrivskyddat, med en integritetskontroll körd på denna maskin.

Allt ovan är den sändande sidan. På boxen som tar emot oföränderliga off-site-kopior från en annan BombVault ger mottagarpanelen dig oberoende, skrivskyddad övervakning av de repositorierna på den mottagande hårdvaran, så att ett tyst fel i den bortre änden inte förblir obemärkt.

Slå på Mottagare-växeln i Inställningar för att avslöja en Mottagare-flik. Den är av som standard; aktivera den endast på en box som faktiskt tar emot oföränderliga off-site-säkerhetskopior. Registrera sedan ett mottaget repository (skrivskyddat, öppnat med den sändande instansens restic-lösenord, som den får via parkopplingsgruppen) för att få:

• En ögonblicksbildsinventering grupperad per källa, så att du exakt kan se vilka containrar, VM:ar och filuppsättningar som har landat.
• Senast mottaget per källa, så att du vet hur färsk var och en är.
• En oberoende restic check körd på den mottagande hårdvaran, så att integritet verifieras där datan faktiskt sitter, inte bara på avsändaren.
• En dödmansknapp: ett larm när en källa slutar sända inom ett fönster du ställer in.
• Integritetslarm: ett larm när en kontroll på den mottagande sidan misslyckas.

Mottagaren är strikt skrivskyddad. Den skriver aldrig till det mottagna repositoriet, så den kan aldrig bryta append-only-garantin som avsändaren förlitar sig på.

Mottagarserver

Mottagarboxen kan också köra den rest-server som de andra kopierar till. Ställ in mottagarserver överst på fliken Mottagare frågar efter en mapp på en resurs, där Ny mapp skapar en, och en port (8000 om ingen annan container använder den). BombVault gör sedan så här:

1. avbryter om en container som heter rest-server redan finns eller om en annan container har porten;
2. hämtar restic/rest-server och startar den via Docker-socketen i append-only-läge med privata arkiv och en inloggningsfil i mappen;
3. skriver dess Unraid-mall till flashen, så att containern går att redigera på fliken Docker, eller erbjuder mallen som nedladdning när flashen inte går att nå;
4. kör manipulationstestet mot den och visar om den vägrar radera.

Instanserna i din grupp hittar sedan servern i målguiden under Från din grupp, med mottagarboxens namn. Varje instans får en egen inloggning första gången den väljer servern och skriver bara till sin egen mapp där. Kortet listar inloggningarna, och Återkalla inloggning tar bort en; det den instansen redan har kopierat ligger kvar i mappen. Konfigurationen skapar också en inloggning för någon utanför gruppen, vars lösenord kortet visar en enda gång.

En instans som når mottagarboxen bara via reläet kan inte använda servern, eftersom reläet inte bär några säkerhetskopior. Lägg först till mottagarboxens adress under Inställningar, Parkoppling. När BombVault körs på en egen IP-adress (till exempel på br0), fyll i Adress för partner, eftersom servern lyssnar på värdens adress.

Genomgånget exempel: två Unraid-maskiner, hela vägen

Ovan beskrivs delarna. Här är en komplett uppsättning med riktiga värden, för delar är lättare att sätta ihop när man har sett dem ihopsatta en gång.

Två maskiner: TOWER kör containrarna och skickar säkerhetskopiorna, VAULT tar emot dem och upprätthåller oföränderligheten. Byt ut mot dina egna namn, adresser och utdelningssökvägar.

1. Res upp append-only-servern på VAULT. I BombVault på TOWER, gå till Inställningar → Extern → Konfigurera, välj rest-server och generera receptet. Kopiera fliken Unraid-mall (XML), spara den på VAULT som /boot/config/plugins/dockerMan/templates-user/my-rest-server.xml, gå sedan till Docker → Add Container och välj rest-server i mallistan. Skriv in den visade htpasswd-raden i /mnt/user/appdata/rest-server/.htpasswd på VAULT innan du startar den. Engångslösenordet visas en gång och sparas aldrig, kopiera det nu. Den raden bär samma lösenord, redan bcrypt-hashat åt dig: klartexten hör hemma i REST-uppgifterna på TOWER, den hashade raden i .htpasswd på VAULT. Du behöver inte hasha något själv.

Låt `--append-only` stå kvar i OPTIONS-fältet. Det är hela poängen: utan det är VAULT en vanlig utdelning igen.

2. Peka det externa arkivet dit på TOWER. Arkivets URL följer mönstret som receptet skriver ut:

rest:http://VAULT:8000/bombvault-containers/containers

Första segmentet i sökvägen är htpasswd-användaren, det andra är arkivet. Ange den genererade användaren och lösenordet som destinationens REST-uppgifter och kör anslutningstestet.

3. Slå på ”Oföränderlig” på TOWER. Manipulationstestet körs direkt och måste säga skyddad. Vad svaren betyder:

Resultat	Vad som hände
skyddad	VAULT vägrade raderingen. Det är det enda godkända tillståndet.
INTE skyddad	VAULT accepterade en radering. --append-only saknas eller har tagits bort.
ej avgörande	Varken eller. Oftast är adressen inte den restic själv använder, eller så har uppgifterna ändrats. Inget registreras och inget larm utlöses.

4. Se på VAULT vad som kommer in. Parkoppla de två boxarna (Parkoppling av instanser), slå på Inställningar → Allmänt → Mottagare, öppna fliken Mottagare och registrera arkivet skrivskyddat med TOWER som sändande instans.

Platsen är en sökväg inuti containern, skriven relativt värdmonteringen

Ange user/appdata/rest-server/bombvault-containers/containers, inte /mnt/user/appdata/…. BombVault kör i en container där värdens /mnt är monterad någon annanstans; en absolut värdsökväg finns inte där. Klistrar du in en sådan talar BombVault nu om vilken relativ sökväg du ska använda i stället.

VAULT hämtar TOWERs restic-lösenord via gruppen när du sparar; ingen behöver skriva in en nyckel.

5. Gör det ömsesidigt, om du vill. Upprepa samma fem steg åt andra hållet: en rest-server på TOWER som tar emot VAULTs kopia. Då upprätthåller varje maskin oföränderligheten åt den andra, och ingen kan radera den andras säkerhetskopior.

Guidad återställning

En dedikerad Återställning-flik lotsar en ny eller ombyggd installation genom katastrofscenariot, på ett ställe:

1. Återställer BombVaults egna inställningar först, så att säkerhetskopiesökvägarna, off-site-målen och uppgifterna som resten av flödet behöver kommer förifyllda (tillämpade via en självomstart över Docker-socketen, så att den körande inställningsdatabasen aldrig skrivs över under ett öppet handtag).
2. Kontrollerar att BombVault kan läsa dina säkerhetskopior (krypteringsnyckel-fällan direkt).
3. Låter dig peka mot ditt befintliga repo (lokalt eller off-site).
4. Identifierar containrarna, VM:arna, filuppsättningarna och ZFS-datauppsättningarna lagrade i det.
5. Återställer containrarna och VM:arna i ett svep (lämnade stoppade, så att du startar dem medvetet) och listar filuppsättningarna och ZFS-objekten som du återställer ett i taget; ZFS-objekt kommer tillbaka avstängda. Ditt återställningskit är ett klick bort.

Planerad migrering kontra katastrof

Guidad återställning återställer BombVaults egna inställningar från en säkerhetskopia. För en planerad flytt till en ny box kan du istället ta med din konfiguration direkt med kortet Exportera / importera inställningar (en portabel JSON-fil). Se Konfiguration.

Återställ från ett annat BombVault-repo

Ett separat kort på fliken Återställning öppnar en annan BombVault-instans repo (en resurs monterad under /mnt, eller en fjärr-URL) med den instansens APP_KEY, i en engångs, skrivskyddad session. Bläddra bland containrarna, VM:arna och filuppsättningarna som lagras där, välj en ögonblicksbild och återställ den, och det återställda objektet blir en normal lokal container, VM eller filuppsättning. Inget skrivs någonsin till det andra repot, och dina egna säkerhetskopieringsinställningar förblir orörda (sessionen lever i minnet och löper ut av sig själv). Att flytta en container från server A till server B innebär inte längre att peka om dina repo-inställningar och återställa dem efteråt. Det här kortet är för en enda gång: det öppnar en session, återställer det du väljer och glömmer den andra instansen. Vill du i stället ha ett stående arrangemang, där den här boxen enligt ett schema hämtar en annan instans ögonblicksbilder till sitt eget repository, är det fliken Hämtning på sidan Instanser.

En container vars nätverk inte finns på den här servern, till exempel ett Unraid-br0-nätverk på en vanlig Docker-värd, visar ett nätverksval under sin rad. BombVault skapar den på nätverket du väljer, tillsammans med dess andra nätverk. Den fasta IP-adressen och MAC-adressen hörde till det gamla nätverket och faller bort, så det nya nätverket delar ut dem.

Återställningskit för krypteringsnyckeln

Detta är delen som gör katastrofåterställning möjlig även när det inte finns någon körande BombVault.

Ett klick laddar ner huvudnyckeln, det härledda restic-lösenordet och de exakta repo-platserna och kommandona, så att du kan återställa direkt med restic-CLI på valfri maskin. En påminnelse på Översikten tjatar tills du har förvarat det.

Förvara återställningskitet bort från servern

Kitet innehåller hemligheten som dekrypterar dina säkerhetskopior. Förvara det på en säker plats åtskild från servern (en lösenordshanterare, en utskriven kopia i ett kassaskåp). Om du förlorar både BombVault och APP_KEY utan något återställningskit kan dina krypterade säkerhetskopior inte återställas.

Den senaste snapshoten är inte alltid den som ska återställas

Sedan restic 0.17 visar restic snapshots storleken på varje snapshot. Efter dataförlust kan den senaste snapshoten vara den tömda, så återställ inte en snapshot som är mycket mindre än de före den. Efter ransomware kan det vara den krypterade, i vanlig storlek. Om BombVault fortfarande körs, titta först på sidan Avvikelser: den anger den senaste bra säkerhetskopian. En återställning behöver inga avvikelsedata från BombVault, och gallringspausen behåller bara fler snapshots.

Försegla kitet

Om du har slagit på age-kryptering för de vanliga exporterna (Inställningar) förseglas kitet också med den och laddas ned som bombvault-recovery-kit.md.age. Det är ASCII-armored i stället för binärt, så det är fortfarande vanlig text: att klistra in det i en lösenordshanterare eller skriva ut det fungerar precis som förut, innehållet går bara inte att läsa utan din nyckel.

Förvara inte age-nyckeln i kitet

Du behöver din privata age-nyckel för att öppna ett förseglat kit. Förvara den någonstans som inte är beroende av själva kitet, annars har du två saker att återställa i stället för en. Förseglingen är värd det när kitet förvaras någonstans du inte har full kontroll över (en delad lösenordshanterare, anteckningar i molnet, en utskrift på ett kontor); ett kit i ditt eget kassaskåp skyddas redan av kassaskåpet.

Med kryptering påslagen och ingen användbar mottagare inställd vägras nedladdningen helt. BombVault faller aldrig tillbaka på att lämna ut huvudnyckeln i klartext.

När paketet inte finns till hands

Lösenordet lagras ingenstans, det beräknas ur APP_KEY. Med nyckeln och ett skal kan du alltså återskapa det själv:

printf 'bombvault:restic-repo' \
  | openssl dgst -sha256 -mac HMAC -macopt hexkey:$APP_KEY -r \
  | cut -d' ' -f1

Det är HMAC-SHA256 över den fasta strängen bombvault:restic-repo, med de råa byten i den hexadecimala APP_KEY som nyckel, utskrivet som 64 gemena hexadecimala tecken. Samma värde står i paketet som det härledda restic-lösenordet; det här är för dagen då paketet ligger någon annanstans än du.

För ett mottaget arkiv, använd den SÄNDANDE instansens nyckel

Ett arkiv som kommit hit via off-site-replikering skapades av maskinen som skickade det, med dess APP_KEY. Att härleda ur den mottagande maskinens nyckel ger ett lösenord som restic avvisar, vilket ser ut precis som ett trasigt arkiv utan att vara det. Det är den vanliga anledningen till att restic check på ett mottaget arkiv frågar efter lösenordet gång på gång.

Eftersom återställningsdefinitioner ligger inuti varje repo (<repo>/def, <repo>/vm-def) är en kopierad repo-mapp helt självständig, så kitet plus repot är allt en bare-metal-återställning behöver.

Hämta tillbaka en databasdump

En databasdump är en egen återställningspunkt i containerförrådet, med etiketten dbdump:<container> och den enda filen /dbdump/<container>.sql. BombVault listar, hämtar och importerar dem under Säkerhetskopior; nedan står samma steg med enbart restic, för dagen då BombVault inte finns till hands.

restic -r <repo> snapshots --tag dbdump:<container>
restic -r <repo> dump --tag dbdump:<container> latest /dbdump/<container>.sql > <container>.sql

Etiketterna dbversion: och dbname: på varje dump säger vilken serverversion den kommer från och vilka databaser den rymmer. En komplett fil slutar med -- PostgreSQL database cluster dump complete eller -- Dump completed.

Importera den i en container med samma eller nyare version (PostgreSQL), eller samma huvudversion (MySQL och MariaDB), startad en gång med tom datamapp så att den initierar sig. Värden behöver ingen databasklient, containern har en:

docker exec -i <container> sh -c 'exec psql -X -U "${POSTGRES_USER:-postgres}" -d postgres' < <container>.sql
docker exec -i <container> sh -c 'exec mariadb -uroot -p"$MARIADB_ROOT_PASSWORD"' < <container>.sql
docker exec -i <container> sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < <container>.sql

För en enda databas ur en full dump tar MySQL och MariaDB --one-database <name> på klientkommandot. En PostgreSQL-dump har ett avsnitt per databas, vart och ett inlett med raden \connect <name>: kopiera det avsnittet till en egen fil och importera den med -d <name> efter att databasen skapats.

En dump tagen som root bär med sig serverns användare

En full MySQL- eller MariaDB-dump tagen som root innehåller systemdatabasen mysql, så en import ersätter den nya serverns konton, root-lösenordet inräknat, med dem från dumpen. På PostgreSQL är role ... already exists för användaren som containern själv skapade väntat och ofarligt.