Funcționalități

BombVault este simplu implicit și profund atunci când ai nevoie. Interfața arată doar elementele esențiale până când comuți switch-ul Vizualizare simplă / Vizualizare avansată. Această pagină grupează întregul set de funcționalități.

Sfera backupului

Containerele, fiecare cu propriul comutator de programare, ordine de copiere și istoric propriu.

Ce	Ce se salvează
Containere Docker	Directorul appdata plus definiția containerului (imagine, variabile de mediu, porturi, etichete, volume). Implicit, întregul director appdata; Alege dosarele pe container bifează exact dosarele pe care le acoperă backupul, cu o numărătoare în timp real a căilor, o listă cu ce ai lăsat deoparte și un comutator Omite folderele de cache pentru fiecare rădăcină (CACHEDIR.TAG).
VM-uri KVM / libvirt	Imaginea (imaginile) de disc a VM-ului, definiția XML și NVRAM-ul UEFI (oprire controlată sau instantaneu live, prin SSH). Instantaneele live revin automat la un backup controlat dacă instantaneul nu poate fi creat, așa că un backup de VM nu eșuează niciodată pur și simplu. Cu Doar blocurile modificate activat, un VM pornit cu discuri qcow2 este citit prin checkpointurile libvirt, deci un backup citește doar blocurile scrise de la cel anterior, iar fiecare snapshot restaurează în continuare singur întregul disc. Discurile aflate pe zvol-uri ZFS sunt transmise cu zfs send prin aceeași legătură SSH, așa că un VM ale cărui discuri sunt zvol-uri primește backup ca un singur VM. Starea unui vTPM în passthrough este salvată lângă NVRAM când XML-ul domeniului îi indică calea. Un vTPM emulat, pe care TrueNAS îl configurează pentru oaspeții Windows 11, nu publică această cale, așa că ține la îndemână cheia de recuperare a unui astfel de oaspete. Vezi ghidul de backup VM.
Flash Unraid	Întregul flash USB (/boot): sistemul de operare, licența, configurația array-ului, partajările, rețeaua și configurația plugin-urilor. Restaurarea este o descărcare .zip cu un singur clic și nu suprascrie niciodată flash-ul în execuție.
Configurația aplicației	Propriul /config al BombVault (baza de date de setări, credențialele off-site, perechea de chei SSH pentru libvirt), fotografiat cu SQLite VACUUM INTO astfel încât o bază de date în mod WAL să nu fie niciodată capturată în mijlocul unei scrieri. Restaurat printr-o auto-repornire, așa că baza de date în execuție nu este niciodată suprascrisă sub un handle deschis.
Fișiere și foldere	Seturi de fișiere denumite: orice folder de pe server (o partajare, documentele tale, o bibliotecă foto), fiecare cu tipare de excludere opționale per set. Paritate completă cu celelalte domenii (programări, retenție, copie off-site, verificări de integritate și exerciții de restaurare).
Seturi de date ZFS	Un set de date împreună cu toate seturile de sub el, citit dintr-un singur instantaneu ZFS, astfel încât toate provin din același moment, și salvat cu restic ca un folder: deduplicat, navigabil, cu fișiere restaurabile individual. Seturile copil noi intră singure, oricare poate fi lăsat pe dinafară, iar unul care nu poate fi citit este sărit și numit. La cerere, containerele sunt oprite sau se rulează o comandă doar pentru momentul instantaneului. Volumele nu sunt incluse: volumul unei VM este salvat împreună cu VM-ul său, un volum fără VM nu este încă salvat. Vezi Seturi de date ZFS.

Restaurare

Recuperarea ghidată duce o instalare nouă prin cazul de dezastru, într-un singur loc.

• Restaurare completă cu un singur clic. Alege un instantaneu, apasă Restaurare. Gata.
• O cronologie per element. Containerele, VM-urile, seturile de fișiere, flash-ul și configurația aplicației își listează backupurile ca o singură cronologie de-a lungul fiecărui loc unde stau, depozitul în care sunt scrise și fiecare țintă off-site. O copie de siguranță trimisă off-site apare o singură dată, marcată cu fiecare loc. Locurile off-site sunt citite când le deschizi, iar ștergerea într-un loc spune dacă a fost ultima copie.
• Containerele sunt reinstalate automat. Definiția containerului este reaplicată prin API-ul Docker, așa că el reapare în fila Docker din Unraid exact cum era.
• GPU-ul, limitele și legăturile revin. Un container restaurat își primește înapoi limitele de resurse, driverul de jurnale, setările DNS, legăturile vechi și GPU-ul sau runtime-ul (--gpus, --runtime=nvidia). Pe o gazdă fără acel driver GPU sau runtime, restaurarea spune asta și oferă Restaurează fără GPU și runtime, și după restaurarea mai multor containere sau a unui stack. O legătură către un container care lipsește, sau care e oprit când pornește cel restaurat, este omisă, iar istoricul rulărilor o menționează.
• VM-urile sunt recreate automat. XML-ul este reimportat prin SSH astfel încât VM-ul reapare în VM Manager cu discul și NVRAM-ul UEFI reatașate, chiar și după ce VM-ul a fost șters. Descoperă copii de rezervă reconstruiește o intrare care a dispărut complet (de exemplu după o instalare nouă).
• Restaurare individuală. Restaurează un container, o VM sau un set de fișiere fără a le atinge pe celelalte.
• Restaurarea flash este o descărcare .zip. Se transmite către browserul tău ca flash-<id>.zip, gata de introdus în creatorul de USB Unraid. /boot-ul în execuție nu este atins niciodată.
• Câte un plugin. Pagina Flash listează pluginurile din fiecare backup al stickului, cu versiune și mărime, și pune un singur plugin înapoi pe stickul în funcțiune: fișierul .plg, dosarul său din config/plugins și fișierele de pachet pe care le conține backupul. Nimic altceva nu se schimbă pe stick. Unraid instalează pluginul la următoarea pornire sau imediat din Plugins, Install Plugin.
• Export ZIP flash programat. După fiecare backup flash, scrie opțional instantaneul ca un simplu .zip într-un folder ales de tine (un singur flash-latest.zip suprascris sau un istoric rulant). Îndreaptă-l către un folder Syncthing sau rclone astfel încât backupul tău de USB bootabil să părăsească automat serverul.
• Verificare de conflicte înainte de zbor. Înainte ca ceva să fie oprit sau eliminat, restaurarea verifică dacă IP-ul static al containerului și porturile publicate ale gazdei sunt libere și se oprește cu un mesaj clar în loc să lase o restaurare pe jumătate terminată.
• Verificări înainte de restaurare. Fiecare dialog de restaurare verifică mai întâi că depozitul răspunde, că cheia salvată îl deschide, că punctul de restaurare există și că destinația are loc pentru ce scrie restaurarea. Pornește rămâne blocat cât timp o verificare eșuează, iar (i) din buton spune care.
• Planul restaurării. Înainte de confirmare, dialogul arată ce face restaurarea față de ce există acum: fișiere noi, înlocuite și neschimbate, cu lista la cerere, și fișierele de la destinație care nu sunt în backup și rămân unde sunt. Pentru containere și VM-uri compară și setările recreate cu cele care rulează: imagine și tag, porturi, nume de variabile și volume, sau memorie, vCPU, discuri și rețea. restic calculează asta ca o rulare de probă după mărime și ora modificării, fără să citească fișierele; un arbore foarte mare se oprește după 30 de secunde și spune asta. Restaurarea unui stack verifică și planifică fiecare membru și îl numește pe cel care o blochează.
• Foldere partajate. O restaurare pe loc numește fiecare alt container, pornit sau nu, al cărui montaj ajunge într-un folder în care scrie, de exemplu "această cale este folosită și de nextcloud-db". Avertizează și nu blochează.
• Restaurare la nivel de fișier. Extinde Fișiere dintr-un instantaneu de container, filtrează, bifează orice număr de fișiere și foldere, apoi restaurează selecția pe loc sau într-un folder ales de tine.
• Restaurare a unui set de fișiere. Restaurează un instantaneu de set de fișiere pe loc (după o confirmare explicită) sau într-un folder ales de tine, niciodată în tăcere. Restaurarea selectivă funcționează și aici.
• Restaurarea unui set de date ZFS. Restaurează un set de date al unui element la locul lui (după un instantaneu ZFS de siguranță care rămâne până îl ștergi), într-un folder sau doar fișierele alese, ori toate seturile unui backup într-un folder. Un set de date nu este niciodată readus înapoi prin rollback și nici înlocuit.
• Restaurarea păstrează starea de rulare. Un container sau o VM care rula când a fost salvat revine în execuție; unul care era oprit rămâne oprit. Bifează Lasă oprit după restaurare pentru a recrea fără a porni.
• Restaurare a unui întreg stack. Containerele din același proiect Docker Compose sunt grupate într-un panou Stack-uri. Restaurează stack-ul… reconstruiește fiecare membru din ultimul său backup lăsat oprit, apoi opțional le pornește în ordinea depends_on.
• Progres live, anulare și feedback de ocupare. O restaurare lungă arată o bară live cu procente și poate fi anulată cu o confirmare conștientă de tip. O restaurare anulată este înregistrată ca anulată, nu eșuată.
• Recuperare ghidată. O filă dedicată Recuperare conduce o instalare nouă prin cazul de dezastru. Vezi Off-site și recuperare.
• Restaurare dintr-un alt depozit BombVault. O sesiune unică, doar în citire, deschide depozitul unei alte instanțe BombVault cu APP_KEY-ul acelei instanțe, astfel încât să poți extrage un container de pe serverul A pe serverul B fără a-ți atinge propriile setări. Vezi Off-site și recuperare.
• Proprietățile ZFS revin. Fiecare backup ZFS păstrează proprietățile setate local ale fiecărui set de date, cum ar fi compresia, dimensiunea înregistrării, cota și sensibilitatea la majuscule. O restaurare într-un set de date nou îl creează cu ele, iar o restaurare într-unul existent le arată și le setează doar dacă ceri. Vezi Seturi de date ZFS.
• Import din pluginul Appdata.Backup. Pe pagina Recuperare, arată-i lui BombVault folderul de backup al pluginului. Fiecare arhivă de container devine un punct de restaurare al containerului său, cu data la care pluginul a creat-o. Arhivele importate anterior sunt sărite, iar arhivele în sine sunt doar citite. Containerul are nevoie mai întâi de un backup în BombVault, ca restaurarea să aibă definiția lui. Retenția nu atinge punctele de restaurare importate, așa că șterge singur unul de care nu mai ai nevoie.

Stocare și programare

• Backupuri incrementale, deduplicate prin restic, așa că nici măcar discurile mari de VM nu umflă depozitul.
• Destinații: o cale locală sau off-site. Partajări SMB și servere WebDAV (Nextcloud, ownCloud, SharePoint) direct dintr-un formular din Setări, Acces cloud, rclone, fără montare pe gazdă; NFS (montează exportul pe Unraid și îndreaptă o cale de backup către el); backenduri restic native fără rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo) sau orice remote rclone prin rclone:<remote>:<bucket>/path. Toate credențialele sunt stocate criptat.
• Țintele SSH nu necesită nimic instalat pe partea îndepărtată. sftp: necesită doar un server SSH, așa că un simplu Raspberry Pi (fără Docker, fără restic) funcționează ca destinație off-site. Cheile gazdei sunt fixate automat la primul contact.
• Copie off-site (local + remote). Păstrează backupul local rapid și adaugă una sau mai multe replici off-site, replicate cu restic copy pe bază de best-effort (o problemă off-site nu eșuează niciodată backupul local). Fiecare domeniu are propria programare off-site, plus un buton Replică acum.
• Mai multe ținte off-site per domeniu. Fiecare domeniu (containere, VM-uri, flash, config, seturi de fișiere și seturi de date ZFS) poate replica către mai multe destinații off-site simultan, nu doar una. Adaugă ținte suplimentare în pagina Extern, fiecare cu propriul depozit, clasă de stocare S3, indicator append-only, retenție și buget de creștere. Copia ta off-site existentă este preluată ca prima țintă, așa că nimic nu se schimbă până nu adaugi a doua, iar fiecare țintă a unui domeniu replică conform programării off-site a acelui domeniu.
• Depozite cu nume. Notează o singură dată locațiile de backup în Setări, Stocare, Depozite, o cale locală sau orice remote restic cu propriul set de credențiale, apoi alege unul ca locație a unui element pe cardul acestuia. Fiecare rând arată câte elemente indică spre el, iar un depozit folosit de un element sau de o amplasare implicită nu poate fi mutat sau șters, pentru că BombVault nu mută niciodată un backup deja scris.
• Mai multe seturi de credențiale cloud. Credențialele cloud comune se aplică peste tot în mod implicit, dar orice destinație poate alege în schimb un set de credențiale cu nume (Setări, Acces cloud, Seturi suplimentare de credențiale), așa că un bucket S3 la Hetzner și un server Garage local pot funcționa unul lângă altul, fiecare cu propria cheie. Asta include țintele off-site și o cale de backup care este ea însăși un depozit la distanță.
• Destinații. O destinație off-site se configurează o singură dată, printr-un asistent care listează serviciile de stocare S3, propriul tău server S3, propriul tău server și partajările tale și fiecare stocare în cloud pe care o acceptă rclone, cu autentificarea, un test de conexiune, un selector de dosar și un cuvânt sincer despre protecția la ștergere. Apoi apare ca buton pe fiecare domeniu și element. Vezi Destinații.
• Amplasare per element. Fiecare card de container, VM și set de fișiere are un rând de butoane, Local și câte unul pentru fiecare țintă off-site, iar cele aprinse primesc copiile de rezervă ale lui. O partajare care stă deja pe un NAS nu mai trebuie să meargă și în B2. Locația este fixată de la prima copie de siguranță, copiile se pot schimba oricând, iar cardul spune câte locuri dețin elementul și dacă regula 3-2-1 este îndeplinită. Vezi Amplasare per element.
• Amplasări implicite. Un rând per domeniu stabilește unde sunt scrise elementele noi și către ce ținte sunt copiate elementele fără alegere proprie. Schimbarea ei nu mută nicio copie de siguranță și spune dinainte ce ținte câștigă sau pierd elemente.
• Ordine manuală de backup. Setează ordinea exactă în care sunt salvate containerele tale din panoul backup-order din pagina Containere. Rulările programate și cele cu selecție multiplă o urmează; orice container lăsat neordonat păstrează comportamentul anterior de tip cel-mai-restant-mai-întâi, iar un backup de un singur container este neschimbat.
• Retenție configurabilă: keep-last / zilnic / săptămânal / lunar / anual, curățat automat după fiecare backup, setat per sursă (atât local cât și off-site în Setări, Retenție, astfel încât să poți păstra copiile off-site mai mult timp ca arhivă). Fiecare sursă poate urma și reguli proprii, local și off-site (Reguli de retenție pe sursă), de exemplu 7 backupuri zilnice pentru containerele care se schimbă zilnic și mai puține pentru VM-urile care se schimbă rar.
• Comprimare per depozit: Oprit, Automat (implicit în restic) sau Maxim, setată în Setări, Stocare pentru fiecare cale de backup și fiecare depozit cu nume și în Setări, Extern pentru fiecare destinație off-site. Backupurile, copiile off-site și curățarea scriu cu ea, iar kitul de recuperare o menționează, ca restic simplu să poată scrie în continuare la fel.
• Programare per domeniu (zilnic / săptămânal, inclusiv seturi de mai multe zile / la fiecare N zile / cron brut), toate editate într-un singur loc în Setări, Programări. Un singur container, VM, set de fișiere sau element ZFS poate avea propria cadență, iar La fiecare N zile funcționează și pentru exercițiul de restaurare, testul de manipulare și rezumatul săptămânal.
• Așteaptă până când aplicația e inactivă. Un container își poate lăsa copia programată să aștepte cât timp aplicația e ocupată, cel mult câte ore setezi, și o pornește imediat ce aplicația e inactivă. Un server media e inactiv când nu face streaming, orice alt container când CPU și traficul rămân câteva minute sub limitele din Setări, Programări (în rețeaua gazdei contează doar CPU). Copia în așteptare apare în jurnalul de activitate și pe container, cu motivul și termenul. Nu ține niciun lacăt, deci celelalte containere merg mai departe. Copiile manuale nu așteaptă niciodată. Membrii unui stack compose programați în aceeași rulare așteaptă împreună, iar o așteptare continuă cu termenul ei după o repornire. Oprirea containerelor anulează toate copiile în așteptare, iar oprirea programării lor le anulează pe cele reținute de rulările ei. Mai puține ore scurtează și o așteptare deja începută.
• Limite de lățime de bandă off-site. Limitează rata de upload/download restic astfel încât replicarea să nu satureze WAN-ul tău.
• Întâi streamingul. Cât timp un server media precum Plex, Jellyfin sau Emby face streaming, copiile externe se încarcă cu o limită mai mică și revin la cea normală la câteva minute după terminarea streamului. BombVault citește din Docker traficul de ieșire al serverelor media. REST, S3, B2, Azure, Google Cloud, Swift și rclone prin HTTP încetinesc în mijlocul copierii; SFTP și folderele locale sau montate primesc limita mică la următorul pas de copiere. Un server media din rețeaua gazdei nu poate fi măsurat. În Setări, Extern.
• Clasă de stocare la rece și de arhivă (S3). Pentru un depozit off-site S3 nativ poți alege clasa de stocare, restricționată la niveluri care permit restaurarea (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval) astfel încât tariful de arhivă să nu strice niciodată o restaurare în tăcere. Nivelurile de arhivă profundă care necesită mai întâi o dezghețare asincronă (Glacier Flexible, Deep Archive) sunt lăsate deoparte intenționat. Doar backenduri S3 native; remote-urile rclone își setează clasa în configurația rclone.
• Folderele de backup rămân copiabile în afara stației. După fiecare backup BombVault relaxează arborele depozitului local la directoare 0755 / fișiere 0644 (depozitele sunt criptate, deci nimic nu este expus) astfel încât un utilizator de sincronizare non-root prin SMB să nu fie blocat. Definițiile de recuperare se află în interiorul fiecărui depozit, deci un folder de depozit copiat este complet autonom.

Perspectivă, verificare și monitorizare

• Pauză direct de pe card. Fiecare card de container, VM și set de foldere are Pune programarea pe pauză, care scoate elementul din programare și din Backup Everything, și Reia programarea pentru a-l readuce. Setează același comutator ca Includeți în programare, așa că cele două sunt mereu de acord. Un element în pauză poartă o insignă gri Programare oprită, iar Copiază acum funcționează în continuare.
• Stare de protecție (RPO). Panoul principal arată un indicator verde / galben / roșu per domeniu, comparând ultimul backup reușit cu programarea sa, astfel încât un backup restant devine roșu în loc să se ascundă într-un jurnal.
• Heatmap de sănătate a backupului. Un calendar în stil contribuții-GitHub cu rezultatele backupului per zi și per domeniu, cu un comutator Containere / VM-uri / Flash / Auto-backup / Foldere.
• Timp de rulare peste tot. Fiecare intrare din istoricul rulărilor arată start, sfârșit (durată), iar fiecare container și VM poartă propria listă Rulări recente pe pagina sa.
• Un panou pe care îl poți rearanja. Comută modul de personalizare pentru a trage cardurile în ordinea ta și a le ascunde pe cele de care nu ai nevoie. Aspectul este salvat per browser.
• Dimensiunea depozitului și tendința de dedup. Dimensiunea curentă a depozitului, raportul de deduplicare și numărul de instantanee per domeniu, cu un sparkline al creșterii stocării.
• Exerciții de verificare a restaurării. BombVault dovedește periodic că backupurile tale pot fi restaurate (restic check --read-data-subset, mărginit) și arată o insignă Restaurare verificată per domeniu.
• Verificarea restaurării după prima copie. Când prima copie a unui element este gata, BombVault restaurează un eșantion din ea (până la 100 de fișiere și 256 MiB) într-un dosar temporar din dosarul de restaurare, pune restic să recitească fiecare fișier față de hash-urile sale și compară dimensiunile cu copia. Pentru un fișier prea mare pentru eșantion, cum ar fi un disc de VM, se recitesc în schimb primii 64 MiB. Cardul elementului arată rezultatul, un eșec vine ca notificare, iar Verifică restaurarea rulează aceeași verificare pe cea mai nouă copie oricând dorești. Copiile următoare nu o repetă.
• Test de pornire. Octeți corecți nu arată că aplicația pornește din nou. Test de pornire pe cardul unui container restaurează cea mai nouă copie într-o copie izolată și o pornește: un nume care începe cu bombvault-test-, o rețea Docker internă proprie fără porturi publicate și fără drum spre LAN, 1 CPU și 2 GiB de memorie, iar datele într-un dosar temporar din dosarul de restaurare. Testul trece când healthcheck-ul containerului raportează sănătos, fără el când primul port expus răspunde din interiorul acelei rețele, iar fără niciunul când rămâne pornit. Containerul original nu este niciodată oprit sau modificat, iar copia, rețeaua și datele ei sunt șterse după aceea, chiar dacă BombVault repornește în mijlocul testului. Containerele din rețeaua gazdei, cele privilegiate, cele cu dispozitive și cele care au nevoie de alt container apar ca netestabile. Activează Test de pornire la verificările programate ale restaurării pentru a testa câte un container la fiecare rulare, începând cu cel testat cel mai demult. Rezultatul apare pe card și în panou. Copia nu poartă nicio etichetă a originalului și rulează fără capabilities, opțiunile de securitate, sysctl-urile și cgroup parent pe care le adaugă originalul. Un container care are nevoie de ele pică testul, iar rezultatul spune fără ce a rulat copia.
• Operațiuni cu auto-vindecare. Un blocaj restic dovedibil orfan (lăsat de o repornire în mijlocul unei operațiuni) este forțat eliberat și reîncercat o dată, automat. Retenția este stabilă ca identitate (curățată per element, imună la schimbări de cale sau gazdă), iar o eșuare de retenție trimite o notificare.
• Avertismente pe care scanarea folderelor nu le vede. Asistentul de excluderi răspunde la o întrebare de dimensiune. Unele dintre cele mai costisitoare greșeli de backup nu sunt întrebări de dimensiune, așa că el poartă și avertismente specifice fiecărei aplicații despre felul în care își stochează datele. Cel pentru care există: Immich păstrează albumele, fețele și datele fiecărei fotografii într-o bază de date PostgreSQL care rulează într-un container separat, așa că un backup la nivel de fișier al containerului Immich restaurează pozele fără nimic din toate acestea, iar restaurarea pare să fi reușit. Avertismentul apare indiferent dacă se oferă sau nu vreo excludere, inclusiv pe un container fără nimic selectat pentru scanare, pentru că avertismentul este adevărat în orice caz.
• Fără backup (acoperire). Un card pe panoul principal care numește tot ce de pe server nu este acoperit de niciun backup automat, cu motivul pentru fiecare: nu a fost adăugat niciodată în BombVault, există dar nu este inclus în programare, are propria programare oprită sau nu este pornită nicio programare nicăieri. Indicatorul de protecție de deasupra răspunde la o altă întrebare, anume dacă backupurile care sunt programate au rulat la timp, și nu poate vedea containerul pe care nu l-a configurat nimeni niciodată: acela lipsește din orice listă și din orice eroare, așa că nimic nu devine galben pentru el. Containerele sunt citite din lista Docker în timp real, nu din rândurile proprii ale BombVault, pentru că un element fără rând este exact cel care trebuie numit. Un tip de backup pe care l-ai oprit este lăsat complet în afara numărătorii, fiindcă asta a fost alegerea ta.
• Previzualizarea retenției. Panoul de lângă setările de retenție arată ce urmează să șteargă următoarea rulare, înainte să se întâmple: per depozit și per element, cu punctele de restaurare numite. Nu ia niciun blocaj pe depozit și nu schimbă nimic, așa că răspunde chiar și în timp ce rulează un backup. O retenție oprită spune asta în loc să arate o listă goală, un depozit append-only este marcat ca atare (acolo retenția nu rulează niciodată), iar un depozit care nu a putut fi contactat este numit în loc să lipsească în tăcere. În Setări, Retenție atât pentru politica locală, cât și pentru cea off-site, fiecare cu propria previzualizare.
• Anomalii. Fiecare backup al unui container, al unei VM, al unui set de foldere, al unui dump de bază de date, al unității flash și al auto-backupului este comparat cu istoricul propriu al acelui element. Verificările se uită la datele noi ale unei rulări, față de cele mai mari cantități obișnuite din backupurile recente și față de ritmul obișnuit pe oră; la un backup care a salvat din nou cea mai mare parte a datelor, inclusiv fișiere redenumite și rescrise; la dimensiunea sursei și numărul de fișiere raportate de restic pentru fiecare element și fiecare dump; la durata backupului măsurată de restic; la serii de eșecuri și eșecuri intermitente; la verificări de restaurare care nu mai trec; și la spațiul liber al depozitelor locale, SFTP și rclone, estimat din creșterea depozitului. Un element învață din primele sale 10 backupuri, în timp ce o sursă aproape goală, rescrierea majorității datelor și eșecurile sunt verificate de la început. La actualizare, istoricul este citit o dată din rezumatele de snapshot pe care le păstrează restic 0.17, așa că o instalare existentă nu pornește de la zero. Sensibilitatea (Strictă, Echilibrată, Permisivă) și gravitatea minimă care trimite o notificare se setează global în Setări, Integritate și pot fi schimbate pe element. Avertismentele se închid singure când cauza dispare; constatările critice despre date pierdute și un disc care se umple rămân până le confirmi, iar o constatare confirmată nu mai este raportată până când cauza ei nu a dispărut o dată. Marchează ca așteptată face un nou nivel normal după 10 backupuri, dar nu dezactivează niciodată verificarea sursei aproape goale, iar după o selecție schimbată istoricul elementului o ia de la capăt singur. Cât timp o sursă este aproape goală, s-a micșorat mult sau un backup a salvat din nou cea mai mare parte a datelor, retenția păstrează backupurile vechi ale acelui element până confirmi constatarea sau o marchezi ca așteptată, iar constatarea trimite la ultimul backup bun. O notificare pleacă o dată pe episod, iar eșecurile și verificările de restaurare care notifică deja nu sunt raportate de două ori. Ce nu face: depozitele S3, B2 și REST nu au o valoare pentru spațiul liber, pe share-ul de utilizator Unraid spațiul liber este cel al întregului array, iar backupurile de dinainte de restic 0.17 nu au istoric de dimensiune. Și elementele ZFS sunt verificate, set de date cu set de date: fiecare set de date al unui arbore are propriul istoric, unul care a fost golit sau nu a mai putut fi citit contează ca pierdere de date și se păstrează doar backupurile vechi ale acelui set. Cum este urmărit un element ZFS set de date cu set de date se descrie în Seturi de date ZFS, iar un asistent poate citi anomaliile deschise prin serverul MCP. O constatare despre dimensiunea sau numărul de fișiere ale unei surse este datată la prima copie în care a apărut, iar Compară cu copia anterioară arată dosarele în care fișiere au dispărut, au apărut sau s-au schimbat, cu o notă când aproape totul se află într-un index de căutare, un cache sau miniaturi pe care aplicația le reconstruiește singură.
• Excluderi recomandate pe aplicație. Pentru imaginile cunoscute (Plex, Jellyfin, Emby, Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Immich, Nextcloud, PhotoPrism și Tautulli, de la linuxserver, hotio, binhex sau editorul oficial), Asistent de excludere propune folderele pe care aplicația le umple singură din nou: cache-uri, jurnale, imagini de previzualizare și postere. Fiecare intrare spune ce conține, oricare poate fi dezactivată și nimic nu este exclus până nu apeși Exclude selecția.
• Pachet de asistență. Un ZIP curățat, cu un singur clic, pentru un raport de eroare: verificarea integrării cu gazda, configurația ta cu fiecare secret eliminat, rulările recente, ce este programat în continuare și jurnalul recent. Conține și cum a decurs ultimul dump al fiecărei baze de date, elementele ZFS cu montările pe care le vede containerul, anomaliile deschise și câte chei MCP există (niciodată numele lor). Parolele, tokenurile, configurația rclone, credențialele de notificare și orice parolă inclusă în locația unui depozit sunt eliminate, iar pachetul spune asta în propriul manifest, pentru că un fișier de asistență nu trebuie confundat niciodată cu un backup al configurației. Cere o parolă de autentificare din același motiv ca kitul de recuperare. Jurnalul pe care îl conține este ieșirea acestui container de la ultima pornire; pentru o cădere care a repornit containerul, docker logs rămâne locul unde trebuie să te uiți.
• Kit de recuperare a cheii de criptare. Descărcare cu un singur clic a cheii principale, a parolei restic derivate și a locațiilor și comenzilor exacte ale depozitului, astfel încât să poți restaura fără un BombVault în execuție. Vezi Off-site și recuperare.
• Exportă și importă-ți setările. Un card Exportă / importă setările pe pagina Setări, Sistem scrie întreaga ta configurație (setări de domeniu, ținte off-site, programări, retenție, notificări) într-un fișier JSON portabil, astfel încât mutarea pe o stație nouă sau clonarea unei configurații să nu însemne reintroducerea totul manual. Alegi dacă incluzi credențialele off-site și de notificare; cu ele, fișierul este la fel de sensibil ca kitul tău de recuperare. Importul arată o previzualizare și cere confirmare și nu îți atinge niciodată datele sau istoricul de backup.
• Notificări. Webhook (Discord / Slack / Gotify / ntfy), Matrix, Healthchecks.io, e-mail (SMTP), un server Apprise API self-hosted și sistemul nativ de notificări al Unraid. Politică per backup: niciodată / la eșec / întotdeauna. O rulare programată a mai multor elemente poate trimite un singur rezumat N din M reușite. Healthchecks primește întregul ciclu de viață (/start, apoi succes sau /fail) ori de câte ori este setat un URL.
• Rezumat săptămânal. Un mesaj pe săptămână prin aceleași canale: numărul de rulări, câte date noi de backup au sosit, dacă off-site-ul este la zi și principalele eșecuri. Dezactivat implicit, cu propria cadență în Setări, Notificări, așa că și o săptămână liniștită este raportată.
• Prometheus /metrics. Opțional (implicit oprit, token bearer opțional) pentru Grafana sau Uptime Kuma. Expune starea, dimensiunile și marcajele temporale ale backupurilor, fără secrete sau căi în etichete.
• API HTTP, Home Assistant și mDNS. Scripturile și panourile primesc un API sub /api/v1 cu tokenuri cu nume, doar în citire sau cu drept de a porni backupuri. Home Assistant găsește BombVault prin descoperirea MQTT, ca dispozitiv cu senzori și, dacă permiți, un buton de backup per domeniu. În plus, BombVault se anunță în rețea ca bombvault.local. Vezi API și integrări.
• Spațiu liber și săptămâni până la umplere. Depozitele locale, depozitele SFTP și destinațiile SMB sau WebDAV care îl raportează își arată spațiul liber și câte săptămâni mai rămân la creșterea actuală. Depozitele S3, B2 și REST afișează "Spațiu liber necunoscut", deoarece aceste backenduri nu îl raportează.
• Dimensiune pe dosar. În secțiunea Copii de rezervă a unui container, a unei VM sau a unui set de dosare, Dimensiune pe dosar arată ce dosare și fișiere ocupă spațiu în cea mai nouă copie și cât din ele a adus ultima copie ca nou sau modificat, câte un nivel pe rând. BombVault citește asta din indexul depozitului fără să citească fișierele și, după ce l-ai deschis o dată, îl actualizează după fiecare copie.
• De ce a fost lentă o copie. Cât rulează o copie, BombVault urmărește cât de ocupate sunt procesorul, discurile și rețeaua. Când o copie durează mult mai mult decât de obicei și un singur lucru a fost clar la limită, rularea o spune, de exemplu „Discul țintă disk1 a fost ocupat 98%” sau „BombVault a folosit 100% din limita de procesor a containerului său”. Altfel nu spune nimic.
• Modificat de la ultima copie. Un container recreat cu altă imagine, alte porturi, variabile sau volume de la ultima sa copie primește un semn lângă nume. (i)-ul lui arată ce s-a schimbat, variabilele doar după nume. Este doar o notă și dispare la următoarea copie.

Protecție împotriva ransomware

• Off-site imuabil (append-only). Marchează un depozit off-site ca append-only astfel încât ransomware-ul sau o gazdă compromisă să nu poată șterge sau rescrie backupurile tale. Partea îndepărtată (un restic/rest-server în mod --append-only) o impune; BombVault doar o verifică și nu arată niciodată verde doar pe baza unei afirmații de configurare.
• Test de manipulare. BombVault dovedește periodic garanția append-only încercând efectiv o ștergere împotriva depozitului off-site (îndreptată către un obiect inexistent): refuzată înseamnă protejat, acceptată înseamnă neprotejat. Un rezultat neconcludent nu răstoarnă niciodată verdictul stocat.
• Configurare off-site ghidată. Un asistent te conduce de la alegerea backend-ului până la un fragment de deploy rest-server gata de lipit, un test de conexiune, comutatorul de imuabilitate și o strategie de retenție.
• Exerciții DR (off-site). Restaurează o țintă reală din depozitul off-site într-un sandbox de unică folosință, verifică-o fișier cu fișier și octet cu octet, apoi curăță. Vezi Off-site și recuperare.
• Fișă de evaluare a protecției împotriva ransomware. Un card pe panoul principal cu o postură verde / galben / roșu per domeniu și o listă de verificare marcată cu vârsta; fiecare rând roșu are link direct către remediu. Devine verde doar pe fapte verificate.
• Alarmă de buget de creștere. Pentru un off-site imuabil (unde instantaneele vechi nu sunt niciodată curățate în mod deliberat), setează un buget de dimensiune și primești o alertă înainte ca acesta să scape de sub control.
• Împerechere prin frază. Instanțele se alătură unui singur grup cu douăsprezece cuvinte: creează fraza pe una, tasteaz-o pe următoarea. Membrii din aceeași rețea vorbesc direct între ei, ceilalți printr-un releu (releul proiectului, unul propriu, sau niciunul), iar fiecare apel dintre ei este criptat de la un capăt la altul. Grupul poartă fișele de evaluare de pe pagina Instanțe, ofertele Mesh pentru off-site și ce are nevoie un receptor sau o sursă de preluare, niciodată date de backup și niciodată APP_KEY. Vezi Off-site și recuperare.
• Pagina Instanțe. Activează Instanțe în Setări pentru o pagină cu un card pentru fiecare instanță din grupul tău, inclusiv aceasta: adresa ei, dacă este conectată și starea de protecție a fiecărui domeniu cu ultimul său backup, în același roșu, galben și verde pe care le arată panoul principal local. Verifică acum cere unui membru să verifice depozitul unui domeniu. Nimic de pe această pagină nu poate porni un backup, restaura sau șterge ceva pe o altă stație.
• Mesh off-site. Un membru poate oferi propriul spațiu de stocare off-site altui membru prin grup. Administratorul celeilalte instanțe vede oferta pe pagina Instanțe și o acceptă sau o refuză; acceptarea creează un set de credențiale și o țintă off-site obișnuite. Pe această cale circulă doar datele de conectare, niciodată datele de backup.
• Panou de recepție (partea de recepție). Pe stația care primește copii off-site imuabile de la un alt BombVault, activează comutatorul Receptor (Setări) pentru a dezvălui o filă Receptor. Înregistrează un depozit primit doar în citire (deschis cu parola restic a instanței care trimite, care sosește prin grupul de împerechere) pentru a vedea inventarul său de instantanee grupat pe sursă, când a sosit ultima dată fiecare sursă și pentru a rula un restic check independent pe hardware-ul care primește. Te alertează când o sursă încetează să trimită într-o fereastră pe care o setezi (un comutator de tip dead-man) sau când o verificare de integritate eșuează. Strict doar în citire, deci nu scrie niciodată în depozitul primit, și oprit implicit. Vezi Off-site și recuperare.
• Preluare de la altă instanță (partea care preia). Imaginea în oglindă a replicării off-site: în loc ca această stație să-și trimită instantaneele în afară, le aduce pe ale altcuiva. Activează comutatorul Preluare (Setări) pentru a dezvălui fila Preluare a paginii Instanțe, alege cealaltă instanță din grupul tău de împerechere și locația depozitului ei, apoi ce tip de backup conține și cât de des să fie preluat. Parola ei restic vine prin grup, niciodată APP_KEY-ul ei. Partea cealaltă nu mai configurează nimic și nu trebuie să fie pornită. Depozitul sursă este doar citit: este deschis pentru a verifica parola, listat și numit ca sursă a copiei, și niciodată inițializat, deblocat, curățat sau scris. Fiecare parte își păstrează propriile credențiale, iar o sursă rclone: este refuzată pentru că rclone ar ajunge la ea cu remote-urile acestei instanțe. Vezi Off-site și recuperare.

Exporturi în clar

• Export în clar de container. Un buton Export (tar simplu) per container scrie o copie navigabilă, fără instrumente, lângă depozit: <name>.tar.gz al folderelor de backup plus șablonul Unraid <name>.xml. Restic rămâne motorul; aceasta este o copie de comoditate suplimentară.
• Export în clar de VM. VM-urile au același Export (tar simplu): <name>.tar.gz al imaginii (imaginilor) de disc plus <name>.xml, restaurabil cu virsh define plus discul, fără BombVault sau restic necesare.
• Criptează exporturile în clar (age). Exporturile se află în afara restic, deci sunt în clar implicit. Activează criptarea age în Setări și adaugă unul sau mai mulți destinatari (o cheie publică age sau o cheie publică SSH). Fiecare export (container și VM .tar.gz, fișierele lor .xml însoțitoare și ZIP-ul flash) este apoi sigilat pentru acei destinatari, iar tu îl decriptezi mai târziu în afara stației cu cheia privată corespunzătoare. Ca regulă de siguranță, cu criptarea activată și niciun destinatar valid setat, un export eșuează cu o eroare clară în loc să scrie vreodată text în clar.
• Și kitul de recuperare este sigilat. Cu aceeași setare activată, kitul se descarcă drept bombvault-recovery-kit.md.age. Este în format ASCII armor, nu binar, așa că rămâne text lizibil: îl poți lipi în continuare într-un manager de parole sau îl poți tipări, adică exact scopul kitului. Se aplică aceeași regulă de siguranță: cu criptarea activată și niciun destinatar utilizabil, descărcarea este refuzată în loc să predea cheia principală în clar. Un lucru de făcut corect când activezi asta: ai nevoie de cheia ta privată age ca să deschizi kitul, așa că păstrează acea cheie într-un loc care nu depinde de kitul însuși.

Asistenți IA (MCP)

BombVault are un server MCP integrat prin care un asistent precum Claude Code sau Claude Desktop poate citi starea copiilor de rezervă, acoperirea, istoricul rulărilor, punctele de restaurare și activitatea în curs. Cu o cheie care îi permite, asistentul poate și să pornească o copie a unui element, a unui domeniu sau a tot și să anuleze copiile pe care le-a pornit. Restaurările, ștergerile, prune și setările rămân în interfața web. Fiecare client primește propria cheie în Setări, Integrări, Server MCP; o cheie apare o singură dată, e stocată doar ca amprentă și poate fi redenumită, înlocuită sau revocată oricând. Pornirile sunt limitate pe oră și pe element, iar o protecție a păstrării împiedică copiile unui asistent să-ți scoată propriile puncte de restaurare dintr-o politică "păstrează ultimele N". Fiecare rulare pornită de un asistent e marcată "prin MCP" cu numele cheii. Vezi Server MCP. Dumpurile de baze de date și seturile de date ZFS se numără printre elementele și punctele de restaurare pe care le citește, și poate lista anomaliile observate de BombVault.

Aplicații și însoțitori

• Aplicația Android. Toate serverele grupului tău pe telefon, cu jurnalul de activitate al tuturor pe un singur ecran. Se împerechează cu grupul tău printr-un cod QR și deschide fiecare server deja autentificat. Vezi Aplicația Android.
• Server receptor. Mașina care primește copiile off-site poate porni un rest-server append-only cu un singur clic și îl poate oferi celorlalte instanțe ale grupului tău, fiecare cu un login propriu. Vezi Server receptor.
• Setări, Aplicații. O pagină care începe cu aplicația Android, cu APK-ul pentru versiunea pe care o rulează serverul și un cod QR pentru el, urmată de un card pentru fiecare însoțitor. Cardul ParleyPort oferă șablonul său Unraid, copiază comanda Docker care îl pornește și duce la depozitul său și la setările releului de la Împerechere. Cardul BombVault Widget oferă șablonul și depozitul său și instalează sau elimină pluginul prin conexiunea SSH la gazdă.
• BombVault Widget. O dală pe Dashboard-ul Unraid cu jurnalul de activitate al BombVault și următoarea rulare programată. Fără o conexiune SSH la gazdă, cardul îți dă adresa .plg de instalat la Plugins, Install Plugin, iar pluginul poate fi eliminat de acolo ca oricare altul.
• Jurnal de activitate încorporabil. Generează un token doar în citire la Setări, Integrări și primești o adresă pentru orice panou care afișează un iframe, cum ar fi Homepage, Organizr sau Heimdall: o pagină mică doar cu jurnalul de activitate în timp real. Tokenul dă acces la acel jurnal și la nimic altceva, iar Dezactivează îl revocă imediat. Pagina încorporată este disponibilă doar în engleză.

Altele

• Oprirea unui backup în curs. Fiecare card care poate porni un backup are un buton Anulează copia lângă bara de progres cât timp rularea este activă. Rularea este înregistrată ca anulată, nu ca eșuată. Oprirea este sigură, pentru că restic își scrie instantaneul la final, așa că o rulare întreruptă lasă date nereferențiate și niciun instantaneu.
• Fă backup la multe simultan. Selectează multiplu containere și apasă Copiază selectatele. Lotul rulează pe partea de server, deci continuă chiar dacă închizi fila sau pierzi conexiunea. BombVault nu face niciodată backup (și deci nu oprește niciodată) propriul său container.
• Browser de instantanee cu o listă de puncte de restaurare, ștergere per instantaneu și un arbore de foldere pliabil pentru restaurare la nivel de fișier.
• Mentenanță a depozitului per domeniu: Verifică (restic check), Deblochează (elimină un blocaj rămas) și Curăță (aplică politica de retenție la cerere când una este setată, altfel o simplă recuperare de spațiu).
• Progres pentru verificare, verificări de restaurare și curățare. Cât timp rulează una dintre ele, jurnalul de activitate și cardul de integritate arată cât a numărat restic, de exemplu 12 din 47 de pachete, iar când există destule date pentru o estimare, și timpul rămas din acel pas. Aici restic numără pachete, instantanee și fișiere de index, nu octeți, așa că asta arată bara; înainte de prima numărătoare se mișcă fără număr.
• Dumpuri automate de baze de date. Containerele PostgreSQL, MySQL și MariaDB recunoscute (imaginile oficiale, PostGIS, TimescaleDB, pgvector, pgautoupgrade, imaginile de bază de date ale Immich, linuxserver, yobasystems și jc21 MariaDB, precum și mysql-server de la Oracle) sunt dumpate înainte de fiecare backup, din serverul aflat în funcțiune. Containerele care doar seamănă cu o bază de date primesc aceeași opțiune pe cardul lor, oprită până când o alegi tu. Dumpul curge direct în depozit și devine acolo un punct de restaurare propriu, lângă backupul de fișiere; pe disc nu este scris niciodată. Datele de autentificare vin din variabilele containerului însuși, inclusiv secretele *_FILE, și nu îl părăsesc. Fiecare card arată dacă folderul de date al bazei este salvat cu containerul oprit, copiat în timp ce rulează, sau deloc salvat. Un dump eșuat nu duce backupul la eșec: apare ca o rulare eșuată cu motivul ei și cu un indiciu de remediere, și trimite o notificare. Dumpurile nu sunt niciodată încărcate înapoi de la sine. Descarcă unul (simplu sau comprimat), salvează-l într-un folder, importă-l cu un clic într-o bază proaspăt pornită, sau scoate-l cu CLI-ul restic. Îl poți opri per container, cu eticheta bombvault.dbdump=false, sau pentru toate containerele în Setări. Detectarea anomaliilor urmărește și dimensiunea fiecărui dump, iar un asistent poate lista dumpurile unui container prin serverul MCP.
• Hook-uri pre/post-backup per container. Comenzi shell rulate în interiorul containerului (de exemplu scrierea unui cache pe disc); un pre-hook eșuat anulează backupul. Bazele de date recunoscute sunt dumpate automat și nu au nevoie de niciun hook.
• Oprește alte containere în timpul backupului, cu o repornire condiționată de sănătate. Numește containere dependente (de exemplu o bază de date) care să fie oprite în timp ce acesta este salvat. Ulterior BombVault le readuce în ordinea depends_on din Compose și, implicit, așteaptă ca fiecare să raporteze că este sănătos (sau în execuție, dacă nu are healthcheck) înainte de a porni containerele care depind de el, astfel încât o dependență precum Pi-hole, o bază de date sau un gateway VPN să fie efectiv activă înainte de serviciile care au nevoie de ea, în loc ca acelea să revină la un connection refused. Așteptarea este mărginită de un timeout per container (120 de secunde implicit) astfel încât un container lent sau niciodată sănătos să nu poată bloca niciodată rularea; atât așteptarea cât și timeout-ul se află în Setări, Containere (dezactivează așteptarea pentru repornirea anterioară toate-deodată). Aceeași repornire ordonată, condiționată de sănătate, învelește și actualizarea imaginii de după backup, așa că într-o zi în care sosește o actualizare, dependenții sunt ținuți jos pe durata recreării și readuși, condiționat de sănătate, doar odată ce s-a terminat.
• Tipare de excludere per container. Listează subdirectoare de sărit în interiorul unui volum salvat, câte unul pe linie. Scrie căile așa cum le vezi în interiorul containerului; o previzualizare live arată la ce se rezolvă fiecare linie și avertizează când o linie nu ar exclude nimic.
• Actualizează după un backup reușit (avansat, oprit implicit). Activează-l pe un container și BombVault descarcă cea mai nouă imagine și îl recreează, dar doar când există efectiv o imagine mai nouă, astfel încât un punct de restaurare proaspăt să existe mereu mai întâi. Extra opționale: o notificare per container actualizat și curățarea imaginilor (o imagine de bază partajată de alte containere nu este niciodată ștearsă). După actualizare BombVault cere de asemenea Unraid să reverifice starea de actualizare a acelui container, astfel încât bannerul învechit update available din fila Docker să se șteargă singur în loc să persiste (actualizările Unraid trec direct prin API-ul Docker, deci starea sa în cache, și pe unele versiuni un digest în cache, ar continua altfel să arate bannerul). Este best-effort, nu afectează niciodată backupul, activat implicit și are un comutator în Setări.
• Restaurare într-un folder alternativ pentru clonare sau inspecție.
• Diff și etichete de instantanee. Compară două instantanee pentru a vedea ce s-a schimbat și etichetează instantaneele pentru a le filtra.
• Ce este nou după o actualizare. Notele de lansare apar o dată per versiune nouă, servite din note încorporate în binar, deci dialogul funcționează offline.
• HTTPS din start (auto-semnat sau adu-ți propriul certificat în spatele unui reverse proxy).
• Healthcheck Docker. Containerul raportează sănătos/nesănătos din propriul /api/health, astfel încât un instrument de auto-vindecare îl poate reporni dacă motorul se blochează vreodată.
• Interfață întunecată/luminoasă în 42 de limbi cu un selector de steag.
• Setările se salvează singure. Comută un întrerupător sau părăsește un câmp și modificarea este scrisă imediat, cu o scurtă licărire pe control și o scuturare dacă serverul o refuză. Trei locuri păstrează un buton Salvează, pentru că o salvare pe jumătate acolo ar fi nesigură: caseta de configurare rclone, editorul de seturi de credențiale și parola de autentificare.
• Mesaje pop-up discrete. În Setări, General poți ascunde confirmările de rutină, astfel încât doar eșecurile să te mai întrerupă. Setarea este per browser și nu atinge notificările trimise de BombVault.
• Așa cum îți place. Setări, Aspect stabilește culorile (un singur accent sau Mod curcubeu cu o paletă de opt), colțurile (rotunjite, ușor rotunjite sau drepte) și animația (dezactivată, discretă, sălbatică sau furtunoasă), reținute per browser. Când sistemul tău cere mai puțină mișcare, acesta are întotdeauna prioritate.