Waardoor veranderen bestandcontrolesommen na het kopiëren via een SMB-share?

SMB transporteert normaal gesproken bestandsbytes ongewijzigd. Een verschil in checksums betekent daarom dat de vergeleken inhoud is gewijzigd, inconsistent is gelezen of niet dezelfde gegevensstroom betrof.

Het verschil kan ontstaan doordat de bron is gehasht voordat een toepassing klaar was met schrijven, doordat aan één kant een resource fork of alternatieve gegevensstroom is vergeleken, doordat een media- of beveiligingstoepassing de bestemming heeft herschreven, doordat een verouderde clientcache is gelezen of doordat er opslag- of transportfouten zijn opgetreden. Bij de juiste test wordt de bron bevroren, worden beide bestanden met dezelfde tool en modus gehasht en wordt de overdracht via een gecontroleerd pad herhaald voordat SMB zelf de schuld krijgt.

Controleer of beide checksums dezelfde bestandsgegevens omvatten

Noteer het exacte bronpad, bestemmingspad, hashopdracht, algoritme, binaire of tekstmodus en tijdstip waarop elke checksum is gegenereerd. Controleer of geen van beide opdrachten een snelkoppeling, symbolische koppeling, tijdelijk bestand of sidecarbestand heeft gelezen.

Het SHA-256-hulpprogramma berekent een digest op basis van de bytes die het uit het opgegeven bestand leest. De sha256sum-referentie ondersteunt het gebruik van hetzelfde algoritme en dezelfde aanroep op beide eindpunten.

Als de bestandsgroottes verschillen, onderzoek dan eerst een onvolledige of gewijzigde kopie voordat je hashes vergelijkt. Als de groottes gelijk zijn maar de hashes verschillen, ga dan verder met de stabiliteit van de bron, het bereik van gegevensstromen, opslagreads en wijzigingen aan de bestemming.

Bevries toepassingen die de bron tijdens het kopiëren kunnen wijzigen

Stop databases, downloadclients, virtuele machines, media-editors, synchronisatietools en alle toepassingen die naar het bronbestand schrijven. Genereer pas een nieuwe checksum van de bron nadat het bestand is gesloten.

De documentatie van Rsync waarschuwt dat bestanden pas naar een bewaakte bronmap mogen worden verplaatst nadat ze volledig zijn geschreven, omdat een veranderend bronbestand inconsistent kan worden overgedragen.

Vergelijk de checksum van de bron vóór en direct na de SMB-kopie. Als de twee bronhashes verschillen, is SMB niet de eerste oorzaak; de bron is tijdens de test gewijzigd.

Controleer oplocks, lokale schrijvers en de gecachte bestandsstatus

Maak een lijst van geopende SMB-handles en lokale processen die toegang hebben tot de bron en de bestemming. Let vooral op situaties waarin dezelfde share gelijktijdig via SMB en rechtstreeks op de NAS-host wordt beschreven.

Samba legt uit dat opportunistische vergrendelingen een client toestaan bestandswijzigingen lokaal te cachen en deze indien nodig terug naar de server te synchroniseren. Het vergrendelings- en oplocks-model laat zien waarom gelijktijdige lokale en SMB-schrijvers tijdens integriteitstests moeten worden beheerst.

Schakel oplocks niet meteen serverbreed uit. Sluit de concurrerende toepassingen, open een nieuwe sessie en herhaal één bestandskopie om vast te stellen of gelijktijdige toegang een rol speelde.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Scheid bestandsinhoud van uitgebreide kenmerken en alternatieve gegevensstromen

Bepaal of de verwachte checksum alleen de hoofdgegevens van het bestand omvat of ook een archief dat resource forks, uitgebreide kenmerken, alternatieve gegevensstromen, ACL's en metadata bevat. Gebruik aan beide kanten hetzelfde bereik.

ArchWiki beschrijft uitgebreide kenmerken als metadata die afzonderlijk van gewone bestandsinhoud wordt opgeslagen. Het verliezen of vertalen van die metadata kan de hash van een archief of pakket wijzigen zonder dat de checksum van de hoofdgegevensstroom verandert.

Vergelijk bij macOS-bestanden de hoofdgegevensfork afzonderlijk van een eventuele resource fork of AppleDouble-sidecar. Zie een metadataverschil niet als bewijs dat de bytes van het primaire bestand zijn gewijzigd.

Gebruik een kopieertool met hervatten en logging

Herhaal de overdracht met één bekende kopieermethode en een nieuwe bestandsnaam op de bestemming. Bewaar het logboek met pogingen, hervattingen, overslagen en fouten in plaats van uitsluitend te vertrouwen op een voortgangsvenster van de bestandsbrowser.

Microsoft definieert SMB als een protocol waarmee toepassingen externe bestanden kunnen lezen, maken en bijwerken. Het SMB-model voor bestandstoegang ondersteunt de conclusie dat een gewijzigde checksum wijst op een probleem in het gegevenspad of bij een schrijver, niet op een verwachte protocoltransformatie.

Als een gelogde kopie via de opdrachtregel wel overeenkomt en slepen en neerzetten niet, vergelijk dan de toepassing, het gedrag bij nieuwe pogingen, de verwerking van gedeeltelijke bestanden, antivirusscans en verwerking na het kopiëren, in plaats van de SMB-server te wijzigen.

Vergelijk de bestemming voordat indexeerders of toepassingen deze herschrijven

Hash de bestemming direct na het kopiëren terwijl het bestand gesloten is en voordat mediascanners, documentconverters, fotobeheerders, antivirusprogramma's of synchronisatieclients het kunnen wijzigen.

De handleiding van Oregon State voor Robocopy benadrukt gelogd en hervatbaar kopiëren. Daarmee ontstaat een duidelijkere grens tussen het voltooien van de overdracht en latere toegang tot de bestemming door toepassingen.

Als de hash van de bestemming direct na het kopiëren overeenkomt maar later verandert, identificeer dan het eerste proces dat het bestand opent om erin te schrijven. De permanente oplossing ligt dan bij het metadata-, optimalisatie- of synchronisatiegedrag van die toepassing.

Herhaal de test over opslag- en netwerkgrenzen heen

Kopieer hetzelfde gesloten testbestand lokaal op de bron-NAS, lokaal op het bestandssysteem van de bestemming, via SMB vanaf een andere client en via de oorspronkelijke client. Bereken na elke stap de hash.

De ZimaSpace-handleiding voor het behouden van metadata bij NAS-migratie biedt de aanverwante regel: inhoudshashes en metadata­velden moeten als afzonderlijke acceptatiecriteria worden gevalideerd.

Het probleem is opgelost wanneer een gesloten bronbestand bij herhaalde kopieën overeenkomende hashes oplevert en ongewijzigd blijft nadat services na het kopiëren zijn uitgevoerd. Stop de migratie en bescherm de bron als verschillen steeds dezelfde schijf, controller, client of reproduceerbare bestandspositie volgen.