paden te lang om te restoren

[Verwijderd]

Dit is een probleem waar ik al vaker tegenaan ben gelopen en waar ik nog steeds geen goede oplossing voor heb.

Als er een restore gedaan moet worden is het meest makkelijk dit te doen via Volume Shadow Copy indien mogelijk.

Maar vaak loop ik dan tegen het probleem aan dat bij een klant die enorm lange mapnamen en bestandsnamen gebruikt het totale UNC pad over de limiet heengaat van 255~260(?) characters.
Als ik daar normaliter tegenaanloop bij bijvoorbeeld een copy actie dan kan je als "trucje" even een tijdelijke share maken of network drive en die mappen zodat het UNC pad korter is. (je laat de share "dieper" aangrijpen).

Maar met "previous versions" kan je uiteraard BINNEN previous versions geen bestanden hernoemen of drive mappings maken!
En dan loop ik dus tegen die MAX_PATH limiet aan.

Nog een workaround is aanloggen op de fileserver ZELF en via lokale volumes previous versions gebruiken.
Echter, de fileserver bij ons is een netapp fileserver op basis van Linux met een webinterface.
Lokaal VCC gebruiken is voor zover ik weet niet mogelijk.

Heeft iemand een workaround voor dit soort problemen?
Ik loop hier namelijk vaak tegenaan met restore acties.

[YellowOnline]

Courant probleem. De limitatie zit 'm in de Windows API en niet in het bestandssysteem, dus je kan je probleem oplossen door een programma te gebruiken dat geen gebruik maakt van die API. ROBOCOPY bijvoorbeeld

[ Voor 8% gewijzigd door YellowOnline op 07-12-2010 19:36 ]

[alt-92]

YellowOnline schreef op dinsdag 07 december 2010 @ 19:36:
ROBOCOPY bijvoorbeeld

en dan nu met Shadow Copies restoren.

Het is meer dat de Shell dat niet doet, want het is wel degelijk mogelijk om op verschillende manieren diepere paden te gebruiken. \\?\X:\path\to\folder bijvoorbeeld...

Als je het voor elkaar kan krijgen om die VSS Snapshot te mounten aan een driveletter (desnoods tijdelijk) zou je dat op die manier kunnen proberen. Ben het ooit eens tegengekomen maar die link ligt @ work

[ Voor 51% gewijzigd door alt-92 op 07-12-2010 19:55 ]

[YellowOnline]

alt-92 schreef op dinsdag 07 december 2010 @ 19:51:
[...]

en dan nu met Shadow Copies restoren.

Het is meer dat de Shell dat niet doet, want het is wel degelijk mogelijk om op verschillende manieren diepere paden te gebruiken. \\?\X:\path\to\folder bijvoorbeeld...

Als je het voor elkaar kan krijgen om die VSS Snapshot te mounten aan een driveletter (desnoods tijdelijk) zou je dat op die manier kunnen proberen. Ben het ooit eens tegengekomen maar die link ligt @ work

O ja, daar kan hij met robocopy niet aan. Die \\? had ik op MSDN gezien, maar dat heb ik nooit geprobeerd en ik zie ook niet echt hoe hij dat kan toepassen met VSS. Maar ik ben wat aan het onderzoeken want het is wel een interessante vraag.

---

Combo van wat alt-92 en ik zeggen:

I did discover the following though, if you view a snapshot using the Previous Versions tab (remember this only works if you browse for files to restore via UNC path) it opens the snap in Explorer, but you can’t map a drive to it or run a command line copy against it…. or can’t you

When you open it in explorer this way it does create a sort of hidden temporary share – easiest way I found to expose the name of the share was to try and zip a file in the explorer session that is looking at the snapshot using WinZip, if you follow the wizard at some point it will expose a UNC path like \\SERVERNAME@GMT-DD-MM-YY-{GUID} if you can cut & paste that you can then map a network drive to it

NET USE * \\servername@gmt-dd-mm-yy-{guid}

En gebruik dan ROBOCOPY om de lange paden probleemloos te kopiëren van de gemounte snapshot naar je doelmap. (Origineel hier)

't Is wel een ad hoc oplossing. Eventueel te scripten als je de juiste GUIDs gemakkelijk te weten kan komen.

[ Voor 42% gewijzigd door YellowOnline op 07-12-2010 20:03 ]

[alt-92]

De GUIDs kun je achterhalen met vssadmin

[Verwijderd]

Yellow en Alt, heel erg bedankt voor het meedenken.
Robocopy was ik ook al tegengekomen, maar die doet inderdaad niks met VSS maar kan wel lange paden ondersteunen.

Dit trucje met GUID's als share mappen is iets wat ik zeker ga proberen.
Grappig, ik bedacht me vanmiddag ook wat er zou gebeuren als ik BINNEN previous versions zou zippen (en waar dat dat kom te staan...) maar winzip stond toevallig niet op die server geinstalleerd en ik heb het idee verder laten varen. En dan lees ik nu dit. LOL.

Op MSDN lees ik het volgende:

The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not be able to interpret properly.

De Windows API en het bestandssysteem zijn dus niet het probleem zoals ik het begrijp maar de applicaties.
De verkenner dus. En blijkbaar is dit in Windows 7 nog steeds het geval.
De hoofdreden hiervoor lijkt te zijn "backwards compatibility" en veiligheid Maar hier ben ik niet zeker van, het zijn wat opmerkingen die ik las.
Irritant is het in ieder geval.

Ik ga er morgen op mijn werk mee verder.
Uiteraard laat ik weten of ik hiermee het probleem kan oplossen en zal ik hier dan de oplossing posten.

UPDATE

Heb het stiekum net al even zitten proberen...
Ik krijg geen GUID te zien in het pad. Wellicht komt dat omdat ik niet op de machine (de fileserver) zelf zit.
Wat ik te zien krijg (en kan je opvragen via properties)

code:

\\unc\path\@GMTdatestring\share

En geen GUID
Een mapping maken hiernaar lukt dus ook niet.
Op de server zelf werken op deze manier kan niet, het is een netapp filer. (linux based met web interface)

grrr, ik ben er bijna!

[ Voor 16% gewijzigd door Verwijderd op 07-12-2010 21:56 ]

[Verwijderd]

alt-92 schreef op dinsdag 07 december 2010 @ 20:20:
De GUIDs kun je achterhalen met vssadmin

Kan dat ook remote?
En is dit wel een GUID? of is dit het SNAPID ?

[ Voor 12% gewijzigd door Verwijderd op 08-12-2010 10:55 ]