Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: dukard op 30 december 2015, 21:30:27
-
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 ... ;)
-
Misschien heb je hier wat aan:
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
-
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.
-
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.
-
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.
-
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.
-
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 ...
-
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 :idea: 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?
-
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.
-
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 ... ;)
-
Let wel op dat je in de juiste map staat voordat je dat uitvoert :!:
-
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.
-
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:
cd ; find /volume1 -print > NAS1.txten op de andere:
cd ; find /volume1 -print > NAS2.txt
Dan haal je beide bestanden naar je PC en kijk je waar de verschillen zitten.
-
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 ;)
-
Altijd nog beter dan opschrijven :lol: ;)
-
Ja, helemaal eens Birdy ... :D
Nogmaals een smart test gedaan op de 3 Tb WD red werknas ... de log laat het volgende lezen:
- Op 30-12-15 en 05-01-2016 een 2-tal sectoren automatisch gerepareerd - schijf gezond.
Kan dit het data verlies tijdens de backup veroorzaken? - het valt namelijk precies samen met mijn activiteiten.
Moet ik nu actie ondernemen ??
-
Na lang zoeken heb ik de ERROR gevonden mbv data software van WD ...
De 6,5 Gb dataloss is gekomen door een aantal 'bad clusters' ... de SMART info gaf aan dat het er 4 waren, maar in werkelijkheid waren het er een stuk meer. Voorzichtig maak ik hieruit op dat de SMART info binnen de NAS omgeving slechts een indicatie is.
Het herstel van de 'bad clusters' leverde met de WD software geen problemen op ... maar ik zet deze schijf niet meer terug in de werkNAS, maar krijgt een ander doel.
Een nieuwe schijf is inmiddels besteld en deze zal ik opnieuw inrichten met een verse DSM
-
Iedereen hartelijk dank voor het meedenken en de bijdragen hebben geleid tot een oplossing ... Tnx ! ;)
-
Beste allemaal,
Graag wil ik dit topic nog even gebruiken voor een tweede ervaring met "lange bestandsnamen" want ik ben recent overgestapt naar grotere schijven in mijn NAS - het DSM netjes vanaf 'scratch' weer opgebouwd met de laatste versie.
Helaas kwam ik bij het overzetten van de data de volgende "errors" tegen:
- Van alle data waren er een stuk of 40 files die gemeld werden dat deze niet gekopieerd konden worden door te lange bestandsnamen
- Van deze files was er niet 1 die daaraan voldeed - als voorbeeld: 'disk3_databackup' met een grootte van 24 mb kon niet worden gekopieerd.
- Het aanpassen van de bestandsnaam door het verwijderen van een letter of underscore werkte wel
- Met het maken van een Zip-bestand kon het ook worden verplaatst naar de nieuwe omgeving.
De hardware:
- NAS systemen zijn beide van Synology
- Schijven zijn beide in ext4
- Beide systemen draaien dezelfde DSM versie
- Staan ingesteld op eigen IP adressen
- Sytemen zijn beide "gezond"
en:
- dit gebeurt alleen binnen de NAS omgeving
- ik heb dit nog niet geconstateerd bij alle 8 andere win7 computers binnen het netwerk
Mijn vraag is dus of iemand enig idee heeft wat zich hier afspeelt en waarom dat ook op willekeurige bestanden lijkt te gebeuren ??
Ik zit hier dus met een raadsel ... ::)