Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Een Docker-volumerestore kan elk bestand byte voor byte opnieuw aanmaken, maar toch uitgebreide attributen verliezen wanneer de back-upindeling, opties, rechten of bestemming deze niet kunnen behouden.

Uitgebreide attributen zijn metadatanaam-waardeparen die buiten de gewone bestandsinhoud, eigenaarschap, modusbits en tijdstempels worden opgeslagen. Ze kunnen ACL-gegevens, SELinux-labels, Linux-mogelijkheden, toepassingsmarkeringen of Samba-metagegevens bevatten. Een eenvoudige op tar gebaseerde volumeback-up kan een map herstellen die compleet lijkt, terwijl toepassingen zich anders gedragen omdat het archief geen xattrs heeft opgeslagen of omdat het herstelproces geen beveiligde naamruimte kon schrijven.

Inventariseer de bronattributen voordat je het herstel herhaalt

Selecteer representatieve bestanden en leg hun hashes, eigenaar, modus, ACL en elke naam en waarde van uitgebreide attributen vast. Neem ook bestanden op die zich na het herstel in de toepassing niet goed gedragen.

Het Linux-xattr-model scheidt de naamruimten user, system, security en trusted, elk met verschillende toegangs- en rechtenvereisten.

Als de bron geen xattrs heeft, zijn deze niet tijdens het herstel verloren gegaan. Als slechts één naamruimte verdwijnt, richt je dan op rechten, beveiligingsbeleid of ondersteuning door de bestemming in plaats van op de bestandsinhoudslaag van het archief.

Controleer wat de Docker-back-upopdracht daadwerkelijk heeft gearchiveerd

Bewaar de exacte image, opdracht, werkmap, archiefindeling, gebruiker, gekoppelde bron en gekoppelde back-upbestemming die door de back-upcontainer zijn gebruikt.

Het volumeback-upvoorbeeld van Docker gebruikt tar in een hulpcontainer, maar het behoud van metagegevens blijft afhankelijk van de tar-implementatie en de geselecteerde opties.

Een geslaagd archiefbestand bewijst dat mapvermeldingen en inhoud zijn gelezen, maar niet dat elke xattr-naamruimte is opgenomen. Inspecteer het archief met hetzelfde hulpmiddel als waarmee het is gemaakt.

Schakel uitgebreide attributen in tijdens het maken en uitpakken van het archief

Vergelijk de tar-opties die bij de back-up en het herstel worden gebruikt. Controleer of xattrs in beide richtingen zijn ingeschakeld en of opname- of uitsluitingspatronen vereiste naamruimten niet hebben verwijderd.

GNU tar vermeldt dat --xattrs uitgebreide attributen opslaat en herstelt.

Als je de optie alleen tijdens het uitpakken toevoegt, kun je attributen die nooit zijn opgeslagen niet terughalen. Maak een nieuw klein archief van een bronbestand met een bekend test-xattr en inspecteer dit voordat je productieve back-ups wijzigt.

Gebruik de juiste Rsync-metagegevensopties voor bestandsback-ups

Als de volumeback-up Rsync gebruikt, controleer dan de opties voor archivering, ACL's, xattrs, numerieke ID's, fake-super en rechten op zowel de verzender als de ontvanger.

De officiële Rsync-handleiding documenteert -X voor het behouden van uitgebreide attributen en beschrijft de opslag met fake-super wanneer metagegevens met verhoogde rechten niet rechtstreeks kunnen worden toegepast.

De gebruikelijke archiefoptie -a omvat niet automatisch alle vereisten voor ACL's en xattrs. Test de exacte opdracht op de daadwerkelijke bron- en bestemmingsbestandssystemen.

Controleer ondersteuning door het bestemmingsbestandssysteem en de koppeling

Maak rechtstreeks op het herstelde volume een tijdelijk bestand en probeer één user-xattr in te stellen, weer te geven en te verwijderen. Herhaal dit via de host en via de back-upcontainer.

Gebruik zowel op de host als in de herstelcontainer een hulpprogramma voor het weergeven van attributen om onafhankelijk van het back-uparchief te bewijzen of de bestemming xattrs accepteert en teruggeeft.

Als het rechtstreeks aanmaken van een xattr mislukt, controleer dan het bestandssysteemtype, de koppelopties, het netwerkprotocol, het volumestuurprogramma en de ondersteuning door het opslagapparaat. Geen enkele archiefoptie kan metagegevens herstellen die de bestemming niet kan weergeven.

Controleer de rechten voor security- en trusted-naamruimten

Leg de containergebruiker tijdens het herstel, mogelijkheden, gebruikersnaamruimte, rootless-modus, SELinux-beleid en vast of het volumepad vanaf de host als bind-mount is gekoppeld.

Red Hat documenteert dat SELinux-labels mogelijk volgens het beleid moeten worden hersteld nadat bestanden zijn gekopieerd of opnieuw aangemaakt.

Geef een back-upcontainer niet permanent brede rechten op de host. Gebruik een gecontroleerde herstelomgeving of herstel eerst gewone gegevens en pas beleidsbeheerde labels daarna opnieuw toe met ondersteunde hulpmiddelen.

Scheid ACL's, mogelijkheden en toepassingsspecifieke xattrs

Vergelijk POSIX-ACL-vermeldingen, Linux-bestandsmogelijkheden, SELinux-labels, user-xattrs en Samba- of macOS-metagegevens afzonderlijk. Ze kunnen om verschillende redenen mislukken.

De xattr_tdb-module van Samba kan xattrs afzonderlijk opslaan van het onderliggende bestandssysteem.

Een volumearchief op bestandsniveau kan de zichtbare bestandsstructuur dus behouden, maar een afzonderlijke Samba-metagegevensdatabase niet. Neem elke afhankelijke metagegevensopslag op of bouw deze opnieuw op via het ondersteunde proces van de toepassing.

Herstel één testbestand en valideer de toepassing

Maak een bekend bronbestand met een inhoudshash, ACL, user-xattr en eventuele vereiste toepassingsmetagegevens. Maak hiervan een back-up en herstel het naar een tijdelijk volume.

Het ZimaSpace-artikel over rechten en metagegevens bij NAS-migraties behandelt algemener migratiegedrag; dit artikel richt zich specifiek op het maken en herstellen van Docker-volumeback-ups.

Het probleem is opgelost wanneer inhoudshashes, vereiste xattr-namen en -waarden, ACL's, beveiligingslabels en het gedrag van de toepassing allemaal overeenkomen na een tweede gecontroleerde back-up en herstel.

Veelgestelde vragen

Zijn uitgebreide attributen hetzelfde als ACL's?

Nee. ACL's kunnen op sommige bestandssystemen worden geïmplementeerd met system-xattrs, maar xattrs slaan ook beveiligingslabels, mogelijkheden, gebruikersmetagegevens en toepassingsspecifieke waarden op.

Behouden tar-archieven standaard uitgebreide attributen?

Ga daar niet van uit. GNU tar biedt expliciete xattr-opties en het archief moet attributen tijdens het maken opslaan voordat het uitpakken deze kan herstellen.

Kunnen xattrs tijdens een herstel verloren gaan, zelfs wanneer dit als root wordt uitgevoerd?

Ja. Het archief kan ze missen, de bestemming ondersteunt ze mogelijk niet, een beveiligingsbeleid kan ze weigeren of de metagegevens kunnen in een afzonderlijke toepassingsdatabase staan.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.