Su Windows: è sicuro fare un robocopy per clonare il sistema?

Vorrei iniziare dando uno sfondo. Sui sistemi Linux, faccio spesso affidamento sul fatto che fino a quando riesco a trasferire tutti i file da un disco rigido a un altro e fino a quando aggiusto il caricatore di avvio, rimarrò con un identico, avviabile, completamente sistema funzionale. La stessa cosa funziona per backup e ripristini (non è richiesto alcun backup speciale dello stato del sistema, solo i file) ... anche MySQL è recuperabile a volte anche quando non era bloccato al momento del backup

Su Windows, non ho mai avuto fortuna con la clonazione del sistema eseguendolo a livello di file. Ho sempre bisogno di uno strumento come VMWare Converter, Ghost, diXML ecc. Che si basano sul prendere l'immagine dell'unità nel suo insieme. All'inizio ho pensato che ciò fosse dovuto principalmente al modo speciale / magico in cui Windows fa il registro e non l'ho messo in discussione (ha funzionato). Fino ad oggi. Mi sono reso conto che questo tipo di pensiero era stupido e che in realtà Windows è anche solo una raccolta di file. Così come test ho preso un'unità server Windows 2003 offline, ho copiato i file su un disco rigido vuoto, ho reso attivo il disco e ... ha funzionato perfettamente!

O l'ha fatto? Perché ho questa paura irrazionale che fallirà solo perché non è un clone testuale come mi sarei aspettato con Ghost? Dovrei avere paura? Perché è stato così facile? I server AD sono diversi? Ci sono casi in cui questo metodo fallirà?

Se la copia file per file è la strada da percorrere, perché quando ho provato a fare la stessa cosa con VSS (esponendo l'ombra copiata C: unità come unità S:) lo stesso approccio non è riuscito. Più specificamente ho ottenuto un sistema di avvio fino alla schermata di accesso. Ha persino accettato la mia password, ma poi ha immediatamente disconnesso il mio utente senza errori nella GUI. Ho anche provato a chiudere tutti i servizi, tranne quelli non bloccabili, prima di copiare ... stesso risultato.

A proposito, sto usando robocopy /E /SECtutte queste operazioni di copia

Sto solo cercando problemi usando questi metodi? So che Ghost ecc. Sono comprovati ... quindi perché reinventare la ruota? ... Ho capito tutto ... ma come professionista voglio sapere perché le cose funzionano così. Ecco perché è importante per me capirlo. (per non parlare della rara possibilità di dover eseguire un ripristino bare metal su un sistema in cui non ho mai avuto un backup dello stato del sistema)

I server AD sono diversi. Un controller di dominio ha una giunzione di directory nella directory C: \ Windows \ SYSVOL \ sysvol che punta alla directory C: \ Windows \ SYSVOL \ domain:

 Directory of C:\Windows\SYSVOL\sysvol

04/13/2011  01:22 PM    <DIR>          .
04/13/2011  01:22 PM    <DIR>          ..
04/13/2011  01:22 PM    <JUNCTION>     domainName.acme.com [C:\Windows\SYSVOL\domain]

Quasi ogni tipo di operazione di copia manuale comporterebbe un SYSVOL che non è in linea a causa di una giunzione interrotta. Sebbene sia accurato, ciò può verificarsi in normali scenari di ripristino, quindi è sempre consigliabile controllare e ricreare la giunzione SYSVOL, se necessario.

A proposito di collegamenti, qualsiasi sistema Windows 2008 / Vista / Windows 7 può avere migliaia di collegamenti nella cartella% SYSTEMROOT% \ System32 per i file binari. Questi target dei collegamenti si trovano effettivamente nella cartella% SYSTEMROOT% \ Winsxs.

Non l'ho confermato, ma Robocopy potrebbe copiare la destinazione anziché il collegamento. Il che spiegherebbe l'opzione / SL :: "copia collegamenti simbolici rispetto al bersaglio".

È possibile che il sistema sembri funzionare correttamente, ma cosa accadrebbe quando è il momento di eseguire un'attività di aggiornamento del sistema, che deve mantenere i file in cui risiedono di solito i target dei collegamenti? Forse li ricreare, ma sarebbe qualcosa che vale la pena testare.

Se sei curioso di sapere come questi link sono stati trasferiti sul disco copiato, puoi fare uno snapshot prima e dopo, quindi confrontare i file usando Windiff o Notepad ++.

È possibile utilizzare il comando seguente per ottenere un'uscita i punti di giunzione su un'unità:

dir C:\ /aL /s  >> junctions.txt  

È possibile utilizzare il seguente script in un file per ottenere un output dei collegamenti per una posizione (ad esempio systemroot):

for /r %systemroot% %%i in (*.exe,*.dll) do (
  echo Checking file: %%i >> file.txt
  fsutil.exe hardlink list "%%i" >> file.txt 2>&1
  echo . >> file.txt
)

Ho eseguito cloni a livello di file (utilizzando l' ntfscloneutilità Linux NTFS Tools ) di Windows 2000 e Windows XP. Non ho provato ntfsclonecon Windows Vista o versioni più recenti, ma non mi aspetto alcun problema. Uso lo strumento di clonazione a livello di file di Microsoft ImageX, abbastanza regolarmente con Windows XP e Windows 7 e non ho problemi. In genere non clonare i computer server, ma mi aspetto ImageXdi funzionare bene con i sistemi operativi del server.

Copiare un filesystem live sarà sempre una sfida. Volume Shadow Copy dovrebbe esporre un filesystem tranquillo ma penso che tu stia ancora correndo le tue possibilità. (Non posso dirti cosa è successo con il tuo volume clonato VSS che non ti avrebbe permesso di accedere. Non è possibile diagnosticare il clone fallito, davvero, davvero difficile). Ti consiglierei sempre di clonare sistemi offline, se possibile.

Supponendo che stai copiando un filesystem completamente quiescente e in grado di ottenere tutti i file le tue uniche preoccupazioni sono:

• Avere un buon record di avvio principale (MBR) e record di avvio della partizione (PBR)
• Avere un buon bootloader

Microsoft bootsect.exepuò essere utilizzato per scrivere buoni MBR e PBR per le versioni precedenti di Windows NT (da NT 3.5 a Windows Server 2003) e BOOTMGR (Windows Vista e versioni successive). Il clone di Windows 2003 deve essere stato su un disco con un formato PBR NT 5.2 (da quando è stato avviato).

Il bootloader NTLDR verrà copiato in una copia a livello di file, il che spiega perché la tua copia di Windows 2003 ha funzionato senza problemi. Il bootloader BOOTMGR può essere installato utilizzando l' bcdboot.exeutilità (inclusa nel supporto di installazione di Windows basato su BOOTMGR).

Non clonerei i computer controller di dominio Active Directory in questo modo. Non si desidera avviare un clone di un controller di dominio sulla stessa rete con il controller di dominio originale perché si tratta di uno scenario completamente non supportato e, probabilmente, non pianificato.

Modifica (ora che ho qualche minuto su un vero computer):

Gli strumenti che ho descritto sopra, ImageXe ntfsclone, sono strumenti di clonazione a livello di filesystem (come Ghost se non viene eseguito in modalità settore grezzo). Interpretano il filesystem NTFS piuttosto che copiare settore per settore. Entrambi questi strumenti non avranno problemi con punti di giunzione o hardlink come ROBOCOPY(senza l' /SLargomento) e XCOPY(con qualsiasi argomento).

In generale, Microsoft non prevede di eseguire la clonazione di sistemi basata su copia a livello di file. Sì, puoi farlo, ma se si rompe riesci a conservare i pezzi.

Il problema con la copia di un filesystem live VSSè che l'istanza esistente di Windows avrà probabilmente la firma del nuovo disco già nel suo registro. Quando si avvia la copia, la firma della partizione da cui si sta avviando viene abbinata al registro e montata come D:o E:, anziché come C:dovrebbe essere.

È possibile risolvere questo problema montando il file di registro e aggiornando HKLM\SYSTEM\MountedDevices Esegui dopo la copia ma prima di riavviare. Volete solo cancellare la \DosDevices\C:voce e cambiare la voce per la vostra nuova unità in C:.