Backup lukt niet door te lange bestandsnamen

[dukard]

Even de situatie schetsen ...

Ik maak al een periode wekelijks en automatisch een backup van mijn "werkNAS" naar een tweede NAS - beide Synology. Dat lukte prima, maar omdat de 2e NAS vol begon te raken heb ik daarvan de twee schijven als JBOD ingesteld om zo een verdubbeling aan schijfruimte te verkrijgen. De instellingen daarvan zijn allemaal correct verlopen.

Met het draaien van een nieuwe Backup in deze setup lijkt alles prima te verlopen, maar na het kopiëren van 810 Gb worden de laatste 6 gb niet meegenomen en laat een error lezen in de logs. De betreffende files konden niet (meer) worden gekopieerd vanwege te lange bestandsnamen.

Mijn vraag ...

Om deze files terug te vinden uit 816 Gb is natuurlijk ondoenlijk ... Is er een slimme manier om deze files terug te vinden en evt. op bestandsnaam te corrigeren?

Alvast dank voor het meedenken ...

[Pippin]

Misschien heb je hier wat aan:

Code: [Selecteer]

rename 's/^(.{5}).*(\..*)$/$1$2/' *http://unix.stackexchange.com/questions/33060/linux-script-or-program-to-shorten-filenames

Gezocht met: shell how to find and rename long filenames

[Birdy]

De betreffende files konden niet (meer) worden gekopieerd vanwege te lange bestandsnamen

Max voor een bestandsnaam is 255 characters en dat is al VEEL.
Heb het idee dat de melding niet helemaal correct is, komt wel vaker voor.
Ik denk eerder aan een oneindig pad dus, een loop, heb dit eerder gezien echter, weet niet meer waar......zal eens zoeken.

[Babylonia]

Met bestanden in achterliggende website-namen en coderingen, kan de lengte aardig oplopen.
Zelf heb ik daar ook wel eens problemen mee gehad, maar kon het vaak herstellen door mappen eerder in de directory korter te benoemen met een enkel cijfer of afkorting.

[Ben(V)]

Ik denk ook dat er iets van een null name of een loop is, want 255 karakters voor een filenaam is wel heel veel.
Die limiet is echt voor de filenaam en niet zoals bij windows voor het hele path(inclusiefs bovenliggende directories dus).

Wat wel mogelijk is dat de backupsoftware andere limieten heeft.

[Briolet]

Er is ook een limiet voor het volledige pad-lengte, maar die is nog hoger volgens de help van Backup&Replica:

De maximumlengte van het volledige pad voor de back-up is 2048 tekens.

De foutmelding gaat over filenaam. Echter zie ik in de help geen limiet voor bestandsnamen genoemd.

[dukard]

Dank voor alle reacties ... 

Ik lees een aantal dingen die geheel nieuw voor mij zijn maar ga er mee aan de slag.
Bij resultaat zal ik het hier melden ...

[dukard]

Ik ben met de aangedragen ideeën nog even aan het zoeken geweest maar helaas niets verder gekomen.

@MMD

Het 'renamen' van bestanden heb ik niet gedaan ... dat zou immers op alle bestanden van toepassing zijn geweest.

-

Nog even wat extra info die wellicht een  laat branden bij jullie ...

- Zowel de "werkNAS" als de Backup NAs draaien beide de laatste- en dezelfde versies van DSM.
- Beide Nassen draaien op een Ext4 indeling.
- Er draaien op beide Nassen geen "third party" services.

- De "werkNAS" maakt elke dag een backup naar een Esata schijf - deze laat alle data (816 Gb) netjes door zonder problemen.

- Voorheen werd bij de wekelijkse backup naar de Backup NAS gewoon alle data netjes gekopieerd.

Maar nu ineens niet meer ...

Iemand die het "licht" heeft gezien?

[Pippin]

Niet persé op alle bestanden.
Zoals de opdracht er staat kort het de bestandsnaam af tot de eerste 5 tekens plus de extentie.
Als je i.p.v. 5 een ander nummer invult, b.v. 200, dan word de bestandsnaam gekort naar "de_eerste_200_tekens.ext"

Of dat de oplossing is weet ik natuurlijk niet maar misschien is het het proberen waard.
Maar zoals reeds gezegd kan de oorzaak ook een andere zijn.

[dukard]

Deze materie is nieuw nieuw voor mij en ben dus enigszins voorzichtig ... maar met deze optie kan ik je voorgestelde idee zeker eens uitproberen.

Tnx ...

[Pippin]

Let wel op dat je in de juiste map staat voordat je dat uitvoert 

[Ben(V)]

Ik zou ook niet zomaar aan het renamen gaan.

Misschien is het slimmer om gewoon een listing te maken van alle bestanden in alle folders en subfolders en de output naar een testfile sturen.
Importeer die textfile in excel, daarna kun je alles bewerken en overzichten maken waar het fout zou kunnen gaan.

[klen]

Volgens mij is het probleem op je BackupNas:

- eSata backup werkt goed
- voordat je de schijf layout veranderde werkte het goed

Ik zou niet renamen, maar proberen uit te zoeken wanneer het fout gaat.
Wat je kan doen is de backup NAS leegmaken en dan nog een keer de job draaien.
Dan proberen om van beide een bestandsoverzicht te maken en het verschil zoeken. Dit is ook wat eerder al is aangeraden.

Als je via ssh of putty inlogt op je servers is het vrij makkelijk te doen:

Code: [Selecteer]

cd ; find /volume1 -print > NAS1.txten op de andere:

Code: [Selecteer]

cd ; find /volume1 -print > NAS2.txt
Dan haal je beide bestanden naar je PC en kijk je waar de verschillen zitten.

[dukard]

Dat klopt ... de backup data verschilt een slordige 6,4 Gb met het origineel en wordt als error aangegeven in de log van de werknas - deze voert immers de opdracht uit.

@klen ... Wat je kan doen is de backup NAS leegmaken en dan nog een keer de job draaien.

Dat heb ik al meerdere keren gedaan ... bij de eerste poging werd er slechts een 560 Gb gekopieerd.
De 2 opvolgende pogingen waren identiek en gaven een verschil van de 6,4 Gb.

De gebruikte schijven zijn allemaal WD red en green en geven geen enkele Smart error - het systeem op beide nassen is "gezond".

-

Dank voor de opdracht regels ...  die uitdraai zal met 815 Gb een aardige worden ... Pff 

[Birdy]

Altijd nog beter dan opschrijven