Data copy met behoud van AGDLP

[Amd-xP]

Binnenkort moet ik Data verplaatsen naar een andere storage lokaal op een server.

Nu is mijn vraag, hoe kan je deze data kopieren/verplaatsen met behoud van rechten?

Zelf zat ik te denken aan Total Commandor met admin.

Graag hoor ik van jullie wat de beste manier is om de rechten te behouden.

[Oogje]

Ik gebruik altijd Robocopy voor dat soort dingen.

[Umbrah]

Afhankelijk van het soort storage, inderdaad: robocopy; maar let wel: dat zit op filesystem niveau; wat er met je shares gebeurt heb je weinig over te zeggen, sterker nog, we weten niet eens wat voor server het is. Is dat uberhaubt wel Windows; en geen geintjes zoals EXFAT?

[Amd-xP]

Is gewoon een Windows 2008 server.
Hier zijn extra schijven in gekomen omdat er te weining huidige storage is.

Mappen zijn wel geshared, maar dat lijkt mij geen probleem te herstellen.

[Croga]

Amd-xP schreef op donderdag 18 juni 2015 @ 08:39:
Is gewoon een Windows 2008 server.
Hier zijn extra schijven in gekomen omdat er te weining huidige storage is.

Ik neem aan dat die schijven in een RAID array zitten? Voeg de nieuwe schijven toe, probleem opgelost, helemaal geen kopieer slag nodig.

[Widow]

Hoe heb je nu je rechten ingedeelt dan.. heb je gewoon een paar hoofdmappen waarop rechten zijn ingesteld, met allerlei submappen die de rechten erfen? Of allerlei mappen overal met aparte rechten op submappen? En doe je het op basis van groepen, of gewoon direct gebruikers rechten geven?

Als je gewoon een paar hoofdmappen hebt, en op de onderliggende mappen heb je niet apart rechten ingesteld (zodat ze de rechten erfen van de bovenliggende map), en je gebruikt overal netjes groepen voor, dan kan je de data gewoon kopieeren en dan de rechten instellen op de hoofdmappen lijkt me

_{Volgens mij heeft AGDLP trouwens niet zoveel te maken met het behouden van rechten op shares}

[Razwer]

Oogje schreef op donderdag 18 juni 2015 @ 08:15:
Ik gebruik altijd Robocopy voor dat soort dingen.

Dat

Croga schreef op donderdag 18 juni 2015 @ 08:42:
[...]

Ik neem aan dat die schijven in een RAID array zitten? Voeg de nieuwe schijven toe, probleem opgelost, helemaal geen kopieer slag nodig.

of als dat mogelijk is dat natuurlijk.

Elke andere oplossing is omslachtig(er)

Widow schreef op donderdag 18 juni 2015 @ 09:10:
Hoe heb je nu je rechten ingedeelt dan.. heb je gewoon een paar hoofdmappen waarop rechten zijn ingesteld, met allerlei submappen die de rechten erfen? Of allerlei mappen overal met aparte rechten op submappen? En doe je het op basis van groepen, of gewoon direct gebruikers rechten geven?

Als je gewoon een paar hoofdmappen hebt, en op de onderliggende mappen heb je niet apart rechten ingesteld (zodat ze de rechten erfen van de bovenliggende map), en je gebruikt overal netjes groepen voor, dan kan je de data gewoon kopieeren en dan de rechten instellen op de hoofdmappen lijkt me

_{Volgens mij heeft AGDLP trouwens niet zoveel te maken met het behouden van rechten op shares}

Timestamps, file/folder owners en alle custom permissions raken zo verloren.
Denk bijvoorbeeld eens aan homefolders. NIET DOEN DUS!

Overigens praten we hier idd over NTFS permissies en niet AGDLP. AGDLP is overigens de term voor de implementatie van RBAC permissies binnen AD en de nesting hier van. Het AGDLP blijft in principe altijd in tact en moeten alleen de share permissies over gezet worden. Iets wat overigens volgens "de Microsoft manier" vaak op "Everyone full control" staat en afgedekt wordt door NTFS permissies.
Wikipedia: AGDLP

[ Voor 61% gewijzigd door Razwer op 18-06-2015 11:17 ]

[peterbr]

Het is zeer goed te doen met de standaard Windows Back-up applicatie die in Windows server zit
Back-up maken en daarna een Restore naar een andere locatie met behoud van de beveiliging. (daarna wel even opnieuw je share aan maken)

[Bor]

Robocopy is de makkelijkste manier. Als je even googled kun je daar erg veel voorbeelden vinden. Denk er om dat je de juiste commandline switches gebruikt.

[Onbekend]

peterbr schreef op zaterdag 20 juni 2015 @ 10:15:
Het is zeer goed te doen met de standaard Windows Back-up applicatie die in Windows server zit
Back-up maken en daarna een Restore naar een andere locatie met behoud van de beveiliging. (daarna wel even opnieuw je share aan maken)

Ik zou die Windows Backup eerst wel goed doortesten.
Je bent niet de eerste dit met Windows Backup een backup hebt gemaakt, waarna je erachter komt dat het niet op een ander systeem te restoren is.

[Bor]

Onbekend schreef op zaterdag 20 juni 2015 @ 10:20:
[...]

Ik zou die Windows Backup eerst wel goed doortesten.
Je bent niet de eerste dit met Windows Backup een backup hebt gemaakt, waarna je erachter komt dat het niet op een ander systeem te restoren is.

Los daarvan, ook een robocopy commandline wil je eerst goed testen natuurlijk. Een foutje is snel gemaakt ondanks dat het niet zo moeilijk is. Je zult niet de eerste zijn die bijvoorbeeld timestamps niet meeneemt doordat een switch is vergeten.

[Umbrah]

Bor schreef op zaterdag 20 juni 2015 @ 10:23:
[...]


Los daarvan, ook een robocopy commandline wil je eerst goed testen natuurlijk. Een foutje is snel gemaakt ondanks dat het niet zo moeilijk is. Je zult niet de eerste zijn die bijvoorbeeld timestamps niet meeneemt doordat een switch is vergeten.

Yup, of een "generieke" /MIR gebruikt wat haast neerkomt op een /PURGE en dan in de doel directory een zeer onaangename verrassing tegenkomt waardoor er vrijdagmiddag 16:55 naar backups gescrambled mag worden...

[peterbr]

Onbekend schreef op zaterdag 20 juni 2015 @ 10:20:
[...]

Ik zou die Windows Backup eerst wel goed doortesten.
Je bent niet de eerste dit met Windows Backup een backup hebt gemaakt, waarna je erachter komt dat het niet op een ander systeem te restoren is.

Dat lijkt me niet echt nodig. Het gaat hier om het verplaatsten van data op een server van plek A naar B
Je maakt een back-up, dan een restore. controleer of het goed op disk staat en daarna verwijder je de oude locatie

[Dennism]

Onbekend schreef op zaterdag 20 juni 2015 @ 10:20:
[...]

Ik zou die Windows Backup eerst wel goed doortesten.
Je bent niet de eerste dit met Windows Backup een backup hebt gemaakt, waarna je erachter komt dat het niet op een ander systeem te restoren is.

Windows backup is de laatste jaren prima te gebruiken. Er zitten natuurlijk niet al te veel features in, en de features die er wel inzitten zijn vrij beperkt t.o.v. enterprise backup oplossingen, maar een simpele file backup + restore is makkelijk met windows backup uit te voeren, al zou ik in dit geval ook iets als robo copy gebruiken.

Het issue dat jij aanhaalt zal je ook vaak met andere backup oplossingen zien gebeuren, en is vaak een issue als je een backup gemaakt van systeem X volledig wil terugzetten op systeem Y (dus met werkend OS, Systemstate e.d.) terwijl systeem Y totaal andere hardware heeft, of UEFI i.p.v. Bios of iets in die richting. Dat gaat inderdaad vaak niet direct goed en zijn er meer stappen nodig om het werkend te krijgen (en soms zal het helemaal niet werken, en zal je gewoon een OS reinstall moeten doen, en dan alleen de data uit de backup toveren).

[Onbekend]

Dennism schreef op zaterdag 20 juni 2015 @ 11:28:
Het issue dat jij aanhaalt zal je ook vaak met andere backup oplossingen zien gebeuren, en is vaak een issue als je een backup gemaakt van systeem X volledig wil terugzetten op systeem Y (dus met werkend OS, Systemstate e.d.) terwijl systeem Y totaal andere hardware heeft, of UEFI i.p.v. Bios of iets in die richting. Dat gaat inderdaad vaak niet direct goed en zijn er meer stappen nodig om het werkend te krijgen (en soms zal het helemaal niet werken, en zal je gewoon een OS reinstall moeten doen, en dan alleen de data uit de backup toveren).

Daar doel ik eigenlijk op. Nieuwe hardware en mogelijk een nieuwe versie van Windows waardoor de Windows Backup niet gelezen kan worden.
Vandaar dat ik (o.a. met Robocopy) backups van files maak, want op een universeel bestandssysteem is dat op veel verschillende computers weer uit te lezen.

[Dennism]

Onbekend schreef op zaterdag 20 juni 2015 @ 12:09:
[...]

Daar doel ik eigenlijk op. Nieuwe hardware en mogelijk een nieuwe versie van Windows waardoor de Windows Backup niet gelezen kan worden.
Vandaar dat ik (o.a. met Robocopy) backups van files maak, want op een universeel bestandssysteem is dat op veel verschillende computers weer uit te lezen.

Windows backup op een bestaande machine kan prima data terughalen uit windows backups gemaakt op eerdere OS versies (i.i.g. kan de 2012 R2 Windows backup versie backups gemaakt op 2008, 2008 R2 en 2012 prima inlezen en data terughalen, 2003 en eerder heb ik niet getest).

Maar een volle Windows backup terugzetten (OS, Systemstate en eventuele data) vanuit de recovery console op een boot CD wil inderdaad op nieuwe hardware nog wel eens lastig zijn. Maar dat geldt ook voor andere backup pakketen. Voor een volledige restore (OS, Systemstate en data) op een machine die al een hogere windows versie heeft zie ik niet echt een use case trouwens. Als je dan perse wil downgraden doe dan een verse OS install, en zet alleen de systemstate en data terug, wat normaliter wel prima kan (zaken als domain controllers in een domain met meerdere DC's daargelaten, maar die wil je eigenlijk sowieso nooit restoren, nuke en reinstall is dan een betere optie)

[ Voor 7% gewijzigd door Dennism op 20-06-2015 12:25 ]

[Onbekend]

Dennism schreef op zaterdag 20 juni 2015 @ 12:23:
Windows backup op een bestaande machine kan prima data terughalen uit windows backups gemaakt op eerdere OS versies (i.i.g. kan de 2012 R2 Windows backup versie backups gemaakt op 2008, 2008 R2 en 2012 prima inlezen en data terughalen, 2003 en eerder heb ik niet getest).

Bij mij is dat nog niet gelukt. Op een zelfde Windows versie die ik op een VM heb geïnstalleerd kon ik met geen mogelijkheid een Windows Backup gebruiken. Dit heb ik meerdere malen in allerlei vormen getest, en mijn collega's (bedrijf dus) kregen dit ook niet voor elkaar. Voor mij geldt een Windows Backup standaard als niet 100% betrouwbaar, maar gelukkig hebben jullie er betere ervaringen mee.

[Dennism]

Onbekend schreef op zaterdag 20 juni 2015 @ 12:42:
[...]

Bij mij is dat nog niet gelukt. Op een zelfde Windows versie die ik op een VM heb geïnstalleerd kon ik met geen mogelijkheid een Windows Backup gebruiken. Dit heb ik meerdere malen in allerlei vormen getest, en mijn collega's (bedrijf dus) kregen dit ook niet voor elkaar. Voor mij geldt een Windows Backup standaard als niet 100% betrouwbaar, maar gelukkig hebben jullie er betere ervaringen mee.

Ik gebruik het zelf ook amper hoor enkel voor een paar niet kritieke fysieke machines die niet gebackupt kunnen worden met onze backup software voor virtuele machines, en vooral vanwege de beperkte opties die Windows server backup heeft. Maar in principe als je gewoon data terug wil halen (zonder complete OS/Systemstate) moet het volgende gewoon werken (gister toevallig nog gebruikt).

1. Sluit je media met Windows Server backups aan op een werkende Windows Server (of zet het op een netwerk schijf).
2. Start windows server backup.
3. Kies voor de optie recover
4. Kies in de wizard voor "backup stored on another location"
5. Kies je locatie waar de backup staan
6.Kies je recovery point
7. Kies je Recovery optie (Losse files of Compleet volume)
8. Kies de files of volumes die je wil recoveren
9. Kies de restore locatie
10. Wacht even en klaar

[Razwer]

Heel schattig om windows backup te gebruiken voor file copy, en kan in bepaalde scenarios handig zijn, maar de logica ontgaat mij om een dubbele copieer slag te doen dmv backup.
1) Normaal gesproken heb je al een backup van jouw files
2) met meer regelmaat dan uitzondering zijn file servers gigantische repositories van data.
3) je bent meer dan 2x zo lang bezig dan wanneer je een directe (robo)copy maakt
4) in de tijd van backup en restore zou de mogelijkheid kunnen zijn dat data niet meer actueel is.

Kortom, met windows backup sla je je data een 3e (4e incl normale backup) keer op, duurt het 2x zo lang en is er kans (afhankelijk van de tijdsduur) dat data niet meer actueel is.

[_H_G_]

Inderdaad. En robocopy leren is sowieso nuttig: je kan er zoveel dingen mee. En ideaal als je later nog iets moet scripten.

offtopic:
Je voelt je wel oud als je zo'n vraag leest en dingen als Total Commander en Windows Backup worden genoemd. Ik zou bij zoiets nog niet eens op de gedachte komen om een gui applicatie te gebruiken. Maar het zal vast en zeker de leeftijd zijn

[Dennism]

Razwer schreef op maandag 22 juni 2015 @ 10:48:
Heel schattig om windows backup te gebruiken voor file copy, en kan in bepaalde scenarios handig zijn, maar de logica ontgaat mij om een dubbele copieer slag te doen dmv backup.
1) Normaal gesproken heb je al een backup van jouw files
2) met meer regelmaat dan uitzondering zijn file servers gigantische repositories van data.
3) je bent meer dan 2x zo lang bezig dan wanneer je een directe (robo)copy maakt
4) in de tijd van backup en restore zou de mogelijkheid kunnen zijn dat data niet meer actueel is.

Kortom, met windows backup sla je je data een 3e (4e incl normale backup) keer op, duurt het 2x zo lang en is er kans (afhankelijk van de tijdsduur) dat data niet meer actueel is.

Klopt zeker, en is ook al diverse malen aangegeven in het topic, ook door de deelnemers aan de windows backup subdiscussie ;-)

[Wim-Bart]

Windows backup is gewoon omslachtig zeker wanneer je op de zelfde server blijft. Een fout is zo gemaakt en voor je het weet overschrijf je een verkeerde disk of folder.

Robocopy is gewoon de methode om te gaan. Robocopy is niet voor niets de vervanger van xcopy geworden. En met robocopy is het allemaal zo simpel.

1. Eerste sync: ROBOCOPY [bron] [doel] /MIR /COPYALL /TEE /NP /ETA /LOG:logbestand /R:0 /W:0
2. Shares omzetten naar nieuwe locatie.
3. Final sync: ROBOCOPY [bron] [doel] /S /E /XO /COPYALL /TEE /NP /ETA /LOG+:logbestand /R:0 /W:0
4. Klaar.

Eventueel shares exporteren via REGEDIT, reg file aanpassen, importeren, reboot klaar.