S3-kompatibel betyder, at et objektlager forstår de samme grundlæggende kald som Amazon S3, så programmer og backupsoftware kan tale med det uden at blive skrevet om. Det betyder ikke, at alle funktioner findes. Hvilke funktioner der mangler, varierer fra lager til lager, og det skal testes før et skifte.
Ordet er udbydernes eget. Der findes ingen fælles standard, som et lager kan certificeres efter, og Data Act (dataforordningen) har bestemmelser om interoperabilitet, men det er ikke bekræftet, at der er udpeget en fælles specifikation for objektlager. “S3-kompatibel” er derfor en påstand, der skal læses som en liste over understøttede kald.
Grænsefladen er den samme
Det, der følger med, er grundmodellen: buckets, objekter, at lægge op, hente, liste og slette, og som regel nøgler til adgang i samme form som hos Amazon. Det er det, de fleste programmer bruger mest, og det er grunden til, at et skifte af objektlager ofte er lettere end et skifte af database.
Ceph Object Gateway er et eksempel. Ceph beskriver sit API som kompatibelt med grundmodellen i Amazon S3 og angiver funktion for funktion, om den er understøttet eller delvist understøttet. Replikering mellem buckets står fx som delvis og er kun tilladt på tværs af zoner.
Funktionerne er det ikke
Uden for grundmodellen begynder forskellene. Garage, et andet open source-objektlager, svarer med fejlkoden “501 Not Implemented”, når et kald ikke findes. Ifølge Garages egen tabel mangler både objektlås og versionering, og livscyklusregler kun er delvist implementeret. For MinIO findes ifølge Garage ingen offentlig liste over S3-kompatibilitet.
Det betyder, at et program, der kun bruger grundmodellen, vil virke, mens et program, der forudsætter versionering eller lås, vil fejle eller opføre sig anderledes. Det farligste tilfælde er backupsoftware, der regner med en lås, som lageret ikke har.
Det, der skal kortlægges
Før et skifte bør I liste de funktioner, jeres programmer faktisk bruger. Den liste er sjældent dokumenteret, og den skal ofte findes ved at læse konfigurationen eller spørge leverandøren af programmet. Typiske punkter er:
Versionering og objektlås. Kræves af de fleste backupprodukter, der lover uforanderlige kopier. Se uforanderlig backup.
Livscyklusregler. Regler, der flytter eller sletter objekter efter en tid. Mangler de, vokser lageret, eller oprydningen skal laves på anden måde.
Replikering. Kopiering til en anden bucket eller region. Kan være delvis eller begrænset til bestemte zoner.
Kryptering. Om lageret krypterer, og om I selv kan styre nøglerne. Nøglemodellerne står i nøgler i cloud.
Adgangspolitikker. Om rettigheder kan sættes pr. bucket og pr. bruger i samme form som før.
Hændelser. Om lageret kan sende besked, når et objekt lægges op, hvis et andet system lytter efter det.
Ydelse. Amazon oplyser grænser for antal kald pr. sekund pr. præfiks og anbefaler at fordele kald over flere præfikser. Andre lagre har andre grænser, og et program, der er indstillet til ét lager, kan opføre sig anderledes på et andet.
Fra Azure Blob
Azure Blob er Microsofts objektlager og bruger en anden grænseflade end S3. Et skifte fra Azure Blob til et S3-kompatibelt lager kræver derfor, at programmerne skifter klientbibliotek eller får et mellemled. Funktionerne skal kortlægges på samme måde. Azure Blob har fx tidsbaserede opbevaringspolitikker, der skal låses for at være uforanderlige, og den model skal genskabes med objektlås i det nye lager.
Sådan testes et skifte
En brugbar fremgangsmåde er at oprette en testbucket i det nye lager og køre jeres egne programmer mod den, med samme indstillinger som i produktionen. Backupsoftwaren skal tage en backup, låse den, forsøge at slette den og gendanne den. Det, der fejler, er listen over arbejde.
Kriterierne for, at testen er bestået, bør skrives før testen. Fx at alle job kører uden fejl i en uge, at låsen afviser sletning, og at en gendannelse giver de samme data som originalen.
Hvad det kræver, og hvad det koster at lade være
Kortlægningen kræver tid fra den, der kender programmerne, og en testkonto hos den nye udbyder. Testen kan ofte gøres på få dage pr. program, med en lav og en høj vurdering afhængigt af, hvor mange funktioner der bruges. Posterne er egne timer, lager og trafik i testperioden og eventuelt timer hos programmets leverandør.
Springes testen over, opdages forskellene i drift. Et backupjob, der fejler stille, eller en lås, der ikke virker, opdages typisk først den dag, kopien skal bruges. Sammenhold testens timer med jeres eget overslag over, hvad en manglende kopi koster.
Det skal I lade være med
- At læse S3-kompatibel som en garanti · det er en betegnelse, og listen over understøttede kald er det, der tæller.
- At teste med et lille script i stedet for jeres egne programmer · det er programmernes brug af lageret, der skal holde.
- At flytte backupen før låsen er prøvet · en backup uden lås er en anden backup end den, I havde.
Det skal valget kunne vise
- ☐ De S3-funktioner, jeres programmer bruger, pr. program.
- ☐ Om det nye lager understøtter dem helt, delvist eller ikke, med kilde.
- ☐ Kriterier for testen, skrevet før den køres.
- ☐ Resultatet af test af backup, lås, sletning og gendannelse.
Kilder
- Ceph Docs, Ceph Object Gateway S3 API: https://docs.ceph.com/en/latest/radosgw/s3/
- Garage, S3 compatibility: https://garagehq.deuxfleurs.fr/documentation/reference-manual/s3-compatibility/
- AWS, Optimizing Amazon S3 performance: https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html
- Microsoft Learn, Immutable storage for Azure Blob: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview
Senest gennemgået: november 2026.
Næste skridt
Bed leverandøren af jeres backupsoftware om en liste over de S3-funktioner, produktet kræver af lageret.
Læs også: Selvdrevet objektlager · Uforanderlig backup
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
