Hoppa till innehåll

Backup av servrar och databaser

En server kan skyddas på två sätt: utifrån, via virtualiseringsvärden, eller inifrån, med en agent i operativsystemet. Valet avgörs inte av tycke och smak utan av vad som körs i maskinen.

För en filserver räcker oftast värdnivån. För en databas gör den det sällan — och det är där de flesta missförstånden uppstår, oftast först den dag någon behöver data tillbaka.

ARJ Distribution säljer uteslutande via återförsäljare och MSP:er i Norden — Sverige, Norge, Danmark, Finland och Island — aldrig direkt till slutkund.

En maskinavbildning ger tillbaka servern. Den ger inte nödvändigtvis tillbaka databasen i det skick kunden förutsatte.

Inifrån eller utifrån — och när vilket

Ligger servern som en virtuell maskin på en hypervisor går det att ta hela maskinen utifrån, utan att installera något i den. Det är den effektiva vägen för de flesta servrar, och den beskrivs på sidan om backup för virtuella miljöer.

Tre situationer kräver i stället en agent inuti servern:

  • Fysiska servrar. Det finns ingen värd att koppla sig till. Skyddet måste sitta i maskinen.
  • Virtuella maskiner där den agentlösa vägen inte är öppen. En fri ESXi-licens, eller maskiner som körs hos en publik eller privat molnleverantör — där skyddas maskinen inifrån i stället.
  • Databaser som ska kunna hanteras som databaser. En maskinavbildning ger tillbaka hela servern, och med applikationskonsistent backup är databasen i den dessutom i ett rent läge. Men ska en enskild databas kunna läggas tillbaka för sig, eller läsas in på en annan server, behövs en riktig databasdump.

I praktiken kombineras nivåerna ofta. Hela maskinen tas på värdnivå för att den ska kunna startas igen, och databasen tas dessutom för sig för att den ska kunna hanteras separat. Det är inte dubbelarbete utan två olika sorters återställning — och det är en av de vanligaste sakerna vi reder ut med partners innan en offert lämnas.

Fysiska servrar

De finns kvar hos fler kunder än man tror — ofta just de maskiner som ingen vågat röra. Två vägar i sortimentet, med helt olika ambitionsnivå.

Xopero ONE

Server Agent skyddar Windows Server från 2008 R2 och uppåt samt Linux — Alpine, Debian, Ubuntu, Fedora, CentOS, RHEL, openSUSE och SLES. Backup på filnivå, på avbildningsnivå och bare metal recovery till ny hårdvara. Samma agent hanterar databaserna längre ner på sidan, och samma konsol täcker klienter, NAS och Microsoft 365.

Hornetsecurity Physical Server Backup

En medvetet avgränsad produkt för fysiska Windows-servrar. Den är applikationsmedveten via VSS, läser bara ändrade block och dubblettrensar inline, och skriver till lokal disk, flyttbar disk eller nätverkssökväg.

Återställningen går bara till Hyper-V — som VHDX-disk eller som virtuell maskin på en Hyper-V-värd. Leverantören kallar den själv en P2V-lösning. Ingen VMware, inga hypervisorvärdar, inga klientoperativsystem och ingen Microsoft 365.

Det viktiga för er är att den finns i två skepnader.

Gratisversionen

Kostnadsfri för slutkunder, och bra att känna till — men känn till villkoren också:

  • Ingen officiell support. Endast leverantörens community-forum.
  • Licensnyckel krävs inom 30 dagar, annars slutar installationen fungera. Nyckeln hämtas via formulär hos leverantören.
  • Varje maskin sköts för sig.

Licensierad via MSP

Det är den här vi helst pratar om med er, för den ändrar både kalkylen och driften.

Den licensieras per server, till samma kostnad som en virtuell maskin. En fysisk server räknas alltså precis som resten av beståndet när ni prissätter ett avtal — ingen särskild post, ingen särskild kalkyl.

Och de licensierade servrarna hanteras i VM Backup, i samma konsol som de virtuella maskinerna. Den fysiska servern blir därmed en maskin bland de andra i översikten, med samma jobb, samma rapporter och samma uppföljning — i stället för en bortglömd låda i ett serverrum som ingen kontrollerar förrän den behövs. Det är skillnaden mellan något ni levererar som tjänst och något kunden installerade själv en gång.

Därför är den värd ett samtal: kunden får ett skydd som inte fanns, till en kostnad som redan ryms i modellen, och ni får in de sista maskinerna i samma övervakning som allt annat. Den dag de virtualiseras är dessutom både vagnen och samtalet redan på plats.

När databasen ligger i en virtuell maskin

De flesta databasservrar är virtuella, och då tas maskinen oftast på hypervisornivå. Det fungerar för databaser också — men bara om en inställning är rätt satt.

Båda produkterna kan ta applikationsmedvetna kopior, och båda bygger på Microsofts VSS: databasen tystas ner ett ögonblick och skriver undan det som ligger i minnet, så att kopian blir likvärdig med en databas som stängts ner ordentligt. Utan det blir kopian kraschkonsistent — ungefär som att dra ur strömmen mitt i en transaktion.

Hornetsecurity VM Backup

Kallar det Application Consistent och sätter det per maskin, under VSS-inställningarna. Leverantören namnger SQL Server, Exchange, SharePoint, Active Directory och Oracle som VSS-medvetna. Kraven skiljer sig mellan hypervisorerna:

  • Hyper-V hanterar transaktionsloggarna som standard, utan någon agent i gästen. Slå bara på alternativet för maskinen.
  • VMware kräver att VM Backup VM Tools distribueras till gästen, och att Truncate Logs är påslaget och visas som installerat.
  • Proxmox VE kräver qemu-guest-agent i gästen, och själva påslaget görs via hypervisorn.

Xopero ONE

Kallar det application-aware backup. För Hyper-V gäller det Windows Server-maskiner, och leverantören beskriver hur VSS tystar applikationerna och håller inne skrivningar i upp till 60 sekunder medan ögonblicksbilden tas. På klienter och servrar slås VSS på under de avancerade inställningarna i backupplanen, med leverantörens egen varning: utan VSS kan backupdata bli inkonsistent.

Ett val att vara medveten om: båda produkterna kan låta backupen fortsätta om det applikationsmedvetna steget misslyckas. Det är praktiskt — man vill sällan att hela jobbet fallerar — men resultatet blir då en kopia utan den konsistensen, och det syns bara i rapporten. Ett grönt jobb är alltså inte samma sak som en applikationskonsistent kopia.

Två undantag som avgör upplägget

VSS är en Windows-teknik. En databas som körs på Linux — PostgreSQL, MySQL eller Oracle — får därför ingen applikationsmedveten ögonblicksbild från någondera produkten. Där är dumpen inifrån inte ett alternativ utan vägen.

Och MySQL är inte VSS-medveten ens på Windows. Hornetsecurity skriver rakt ut att applikationskonsistent backup därför inte går att få för den. En MySQL-databas behöver alltså en dump inifrån oavsett operativsystem och oavsett hur själva maskinen tas. Det är en av de vanligaste luckorna vi hittar när vi går igenom en befintlig miljö — maskinen är skyddad, men databasen i den är det inte på det sätt någon trodde.

Databaser inifrån — så fungerar Xopero ONE

Behövs databasen som en egen enhet — för att kunna läsas in på en annan server, för att den körs på Linux, eller för att maskinen inte tas på hypervisornivå — görs backupen inifrån. Här finns ett missförstånd värt att reda ut tidigt: Xopero ONE läser inte databasen direkt. Ett förberedande skript ber databasen själv skapa en dump med sitt eget verktyg, och därefter säkerhetskopieras dumpfilen som vilken fil som helst.

Upplägget är detsamma för alla fyra motorerna, men villkoren skiljer sig åt:

Motor Plattform Värt att veta
Microsoft SQL ServerWindowsKräver SQL Server-autentisering — Windows-autentisering nämns inte i dokumentationen. Full och differentiell dump väljs med en parameter. Anges ingen databas tas alla på servern.
MySQLWindows och LinuxDumpen görs med mysqldump, och leverantören anger stöd för alla MySQL-versioner som Oracle själva underhåller. MariaDB nämns inte — fråga oss om kunden kör det.
PostgreSQLWindows och LinuxDumpen görs med pg_dump. En databas i taget, eller alla med en parameter.
OracleEndast LinuxFrån version 19c. Kopian görs med RMAN och databasen måste köras i ARCHIVELOG-läge. Tre villkor som alla måste stämma.

Vad man faktiskt gör vid en återställning

Frågan ”kan backupen skriva tillbaka direkt i databasen?” kommer nästan alltid. Den är rimlig att ställa, men svaret betyder mindre än man tror — för det är sällan så en återställning går till i verkligheten.

Är hela databasen borta läser man in hela kopian. Det är det enkla fallet, och där gör dumpfilen precis vad den ska.

Men det vanliga ärendet är ett annat. Något har ändrats eller försvunnit, och ingen vet riktigt vad. Då vill man inte skriva över hela databasen med en gammal kopia — man vill se hur det såg ut innan. Arbetsgången blir att läsa in kopian vid sidan av, jämföra med sina egna databasverktyg och sedan flytta tillbaka just det som ska tillbaka. Det sista steget görs i databasverktyget, inte i backupprogrammet — oavsett vilken backupprodukt kunden har.

Därför är en dumpfil sällan ett sämre utgångsläge. Den går att läsa in på en annan server utan att röra produktionen, vilket är precis vad som behövs när man letar. Det som ska finnas med i en RTO-beräkning är att inläsningen tar tid — inte att metoden skulle vara sämre.

Det som däremot är värt att fråga kunden är hur mycket som får gå förlorat om hela databasen måste återställas. Leverantörens dokumentation nämner inte transaktionsloggar, binlog eller WAL för någon av motorerna, så planera med att den senaste dumpen är det som finns. För de flesta system är det rimligt. För ett affärssystem där varje order räknas är det en fråga vi tar med leverantören innan något lovas.

Fyra sätt att få en backup utan databas i

Alla fyra ger ett jobb som rapporterar grönt. Det är just därför de är värda att känna till.

  • Applikationsmedveten backup slogs aldrig på — eller fallerade tyst. Gäller virtuella maskiner. Kontrolleras per maskin, och rapporten är det enda ställe där ett misslyckat VSS-steg syns.
  • Dumpkatalogen ligger inte i urvalet. Skriptet skriver dumpen till en katalog, och den katalogen måste också vara vald som data att skydda. Missas det körs backupen varje natt utan att databasen någonsin följer med.
  • Skriptet får inte fälla jobbet. Det finns två inställningar: vänta tills skriptet är klart, och låt jobbet misslyckas om skriptet misslyckas. Utan dem kan dumpen fallera tyst medan backupen rapporterar framgång — och då säkerhetskopieras gårdagens dump om och om igen.
  • Förutsättningarna stod aldrig rätt. Oracle på Windows går inte. Oracle utan ARCHIVELOG går inte. Microsoft SQL med enbart Windows-autentisering går inte. Det är snabbt kontrollerat i förväg och dyrt att upptäcka efteråt.

Till alla fyra motorerna rekommenderar leverantören dessutom ett dedikerat databaskonto för backupen — samma princip som gäller backuplagringen: skyddet ska inte falla för att någon annan behörighet gör det.

Fem frågor att ställa kunden

De här avgör vad som går att lova, och vi behöver svaren för att kunna räkna på en affär:

  1. Fysiska eller virtuella servrar? Är de virtuella börjar diskussionen på hypervisornivå — och då är första kontrollen om applikationsmedveten backup är påslagen för databasmaskinerna.
  2. Vilka databasmotorer, vilka versioner och på vilket operativsystem? Linux betyder dump inifrån. Oracle på Windows faller bort direkt, Oracle före 19c likaså, och MySQL kräver dump oavsett.
  3. När behövde ni senast något ur en databasbackup — och vad var det? Svaret är nästan alltid ”något som ändrats”, inte ”hela databasen”. Det styr upplägget mer än någon funktionslista gör.
  4. Hur mycket får gå förlorat om hela databasen måste återställas? Är svaret ”ingenting” är det början på ett samtal med oss, inte slutet på ett.
  5. Vilket konto kör backupen? Ett dedikerat konto — inte en domänadministratör, och inte samma konto som allt annat använder.

Därför via distributör

Vi säljer inte till slutkund. Det är inte en artighet utan affärsmodellen: allt går via er, och vi konkurrerar aldrig med er hos kunden.

Vad ni får utöver licenserna: teknisk försäljningshjälp innan affären, hjälp i proof of concept, support på svenska och engelska, och en kontaktperson som känner er affär i stället för ett ärendenummer. Databaserna är dessutom det område där vi oftast får frågor som kräver ett besked från leverantören — dem tar vi åt er.

Kom igång

Berätta vilka servrar och databasmotorer kunden kör och hur mycket som får gå förlorat, så säger vi vad som går att lösa med produkterna i dag och vad som behöver stämmas av först.

Läs vidare

Om innehållet på den här sidan. Det här är en säljinriktad översikt — inte fullständig produktdokumentation. Uppgifterna är kontrollerade mot leverantörernas egen dokumentation i oktober 2026 och vi ser över dem löpande, men funktioner, systemkrav och versionsstöd ändras — och en ändring kan passera oss. Stäm därför alltid av mot leverantörens aktuella dokumentation innan något utlovas till en kund: Hornetsecuritys kunskapsbas och Xoperos helpcenter för Xopero ONE. Det gäller särskilt databasmotorernas versioner och villkor, som ändras oftare än resten. Är ni osäkra är det snabbare att fråga oss — vi tar frågan med leverantören och återkommer med ett besked ni kan luta er mot i en offert. Och fungerar något inte som det står — här eller i leverantörens dokumentation — säg till oss. Vi anmäler det till leverantören och rättar sidan.

Berätta om ert projekt