Mauvais disque dur et robocopy


1

Après que mon lecteur de disque dur m'ait donné des erreurs CRC, je voulais copier un lecteur sur un autre et choisir un nouveau lecteur de disque dur de 1 To.

J'utilise la commande:

robocopy G: J: /MIR /COPYALL /ZB

Il a d'abord essayé de copier le fichier plusieurs fois (je ne comptais plus, ce n'est plus dans ma fenêtre) et a obtenu une erreur d'accès refusé, erreur 5. Ensuite, il a essayé à nouveau et a été verrouillé. J'ai essayé de copier ce fichier spécifique (14 Mo) et Windows a déclaré "Je ne peux pas lire à partir d'un fichier source ou d'un disque".

J'ai recommencé Robocopy. J'espère qu'il l'ignorera après une tentative d'échec ou deux, mais quelles options puis-je utiliser pour dire que si cela ne fonctionne pas, continuez jusqu'au fichier suivant? Cela ressemblait à cela, mais pour ce dernier, il a été répété plus de quatre fois et finalement bloqué.

Je suis ouvert à d'autres solutions de copie. Je préfère les solutions intégrées. J'utilise Windows 7.

Aussi, comment pourrais-je faire cela sans l' /MIRoption? Est /S /Eassez bon? drapeau référence ici

Je vois que je peux contrôler les tentatives avec / R: <montant>, mais je suis toujours ouvert aux solutions alternatives.

Cela semble prendre quelques minutes avant qu'il ne décide que l'essai a échoué. Puis-je le raccourcir? Le fichier est bloqué à 20,8% depuis un moment.

J'ai essayé une application de récupération de données. Il a essayé de récupérer les données et NE PAS les marquer comme non valides ou corrompues. Bien que j'ai reçu un message indiquant que le secteur XYZ avait une erreur d'entrée / sortie, continuez? mais cela ne m'a pas donné le nom du fichier corrompu. Je ne veux pas ça. La meilleure solution pour moi est d’obtenir tous les bons fichiers + les noms des fichiers invalides.

Réponses:


1

Comme vous l'avez remarqué, vous /r:3ferez trois tentatives au lieu de 1 million (!)

/w:10 attendra 10 secondes entre les tentatives (la valeur par défaut est 30).

Si vous effectuez une copie locale, je ferais deux tentatives avec une attente d'une seconde entre elles (je garde l'attente de 30 secondes lorsque je fais des copies en réseau au cas où je débrancherais le câble).

Aussi ne pas utiliser /mircar il supprime les fichiers dans la destination qui n'existent pas dans la source (qui importeraient si vous exécutez cette commande plusieurs fois) - /Esuffit.

Si vous utilisez /copyall, pensez à exécuter l'invite de commande en tant qu'administrateur, sinon il ne sera probablement pas en mesure de définir correctement toutes les listes de contrôle d'accès.

Ensuite, chkdsk /rtenterez de récupérer les fichiers des secteurs défectueux.


2

J'ai écrit un petit script PowerShell pour ignorer les erreurs d'E / S du périphérique lors de la copie (et ainsi remplacer les données illisibles par des zéros). Une version mise à jour et plus avancée est disponible ici . Le code que j'ai placé ci-dessous est l'une des premières versions et aussi simple que possible:

## .SYNOPSIS
#########################
## This script copies a file, ignoring device I/O errors that abort the reading of files in most applications.
##
## .DESCRIPTION
#########################
## This script will copy the specified file even if it contains unreadable blocks caused by device I/O errors and such. The block that it can not read will be replaced with zeros. The size of the block is determined by the buffer. So, to optimize it for speed, use a large buffer. T optimize for accuracy, use small buffer, smallest being the cluster size of the partition where your source file resides.
##
## .OUTPUTS
#########################
## Errorcode 0: Copy operation finished without errors.
##
## .INPUTS
#########################
## Blabla..
##
## .PARAMETER SourceFilePath
## Path to the source file.
##
## .PARAMETER DestinationFilePath
## Path to the destination file.
##
## .PARAMETER Buffer
## I makes absolutely no sense to set this less than the cluster size of the partition. Setting it lower than cluster size might force rereading a bad sector in a cluster multiple times. Better is to adjust the retry option. Also, System.IO.FileStream buffers input and output for better performance. (http://msdn.microsoft.com/en-us/library/system.io.filestream.aspx).
##
## .EXAMPLE
## .\Force-Copy.ps1 -SourceFilePath "file_path_on_bad_disk" -DestinationFilePath "destinaton_path"
##
#########################

[CmdletBinding()]
param(
   [Parameter(Mandatory=$true,
              ValueFromPipeline=$true,
              HelpMessage="Source file path.")]
   [string][ValidateScript({Test-Path -LiteralPath $_ -Type Leaf})]$SourceFilePath,
   [Parameter(Mandatory=$true,
              ValueFromPipeline=$true,
              HelpMessage="Destination file path.")]
   [string][ValidateScript({ -not (Test-Path -LiteralPath $_) })]$DestinationFilePath,
   [Parameter(Mandatory=$false,
              ValueFromPipeline=$false,
              HelpMessage="Buffer size in bytes.")]
   [int32]$BufferSize=512*2*2*2 # 4096: the default windows cluster size.
)

Write-Host "Working..." -ForegroundColor "Green";

# Making buffer
$Buffer = New-Object System.Byte[] ($BufferSize);
$UnreadableBits = 0;

# Fetching source and destination files.
$SourceFile = Get-Item -LiteralPath $SourceFilePath;
$DestinationFile = New-Object System.IO.FileInfo ($DestinationFilePath);

# Copying starts here
$SourceStream = $SourceFile.OpenRead();
$DestinationStream = $DestinationFile.OpenWrite();

while ($SourceStream.Position -lt $SourceStream.Length) {
    try {

        $ReadLength = $SourceStream.Read($Buffer, 0, $Buffer.length);
        # If the read operation is successful, the current position of the stream is advanced by the number of bytes read. If an exception occurs, the current position of the stream is unchanged. (http://msdn.microsoft.com/en-us/library/system.io.filestream.read.aspx)

    }
    catch [System.IO.IOException] {

        Write-Warning "System.IO.IOException at $($SourceStream.position) bit: $($_.Exception.message)"
        Write-Debug "Debugging...";

        $ShouldReadSize = [math]::Min([int64] $BufferSize, $SourceStream.Length - $SourceStream.Position);

        $DestinationStream.Write((New-Object System.Byte[] ($BufferSize)), 0, $ShouldReadSize);
        $SourceStream.Position = $SourceStream.Position + $ShouldReadSize;

        $UnreadableBits += $ShouldReadSize;

        continue;
    }
    catch {
        Write-Warning "Unhandled error at $($SourceStream.position) bit: $($_.Exception.message)";
        Write-Debug "Unhandled error. You should debug.";
        throw $_;
    }

    $DestinationStream.Write($Buffer, 0, $ReadLength);
    # Write-Progress -Activity "Hashing File" -Status $file -percentComplete ($total/$fd.length * 100)
}

$SourceStream.Dispose();
$DestinationStream.Dispose();

if ($UnreadableBits -ne 0) {Write-Host "$UnreadableBits bits are bad." -ForegroundColor "Red";}

Write-Host "Finished copying $SourceFilePath!" -ForegroundColor "Green";

0

Vous ferez mieux d'utiliser des outils de récupération de données tels que GetDataBack, qui connaissent le lecteur défaillant et s'attendent à ce que les lectures échouent.


Est-ce qu'il essaiera de récupérer les données erronées et de me donner un fichier invalide partiellement récupéré? Je peux plutôt ne pas avoir cela ou du moins marquer comme fichier partiel / invalide.

Il semble que le système essaiera de récupérer le fichier et ne le marquera pas comme non valide / corrompu. Je ne veux pas ça. Mais bonne idée avec l'application de récupération de données.

Lorsque vous utilisez le navigateur de système de fichiers, il indique si le fichier contient des secteurs défectueux.
ta.speot.is

0

J'utilise robocopy pour tous mes transferts de sauvegarde entre appareils. Comme le copier / coller normal n'est pas fiable et que certaines applications ne permettent pas complètement de mettre en pause ou de continuer là où la copie a échoué.

robocopier la destination source / e / XO / copie: DAT / r: 3 / w: 5

Ou raccourcissez les tentatives et les délais d'attente.

En expérience / e est la meilleure option que / MIR et vous n’auriez alors pas besoin de / s

De même, si votre copie a été interrompue pour quelque raison que ce soit, utilisez / XO pour ignorer les fichiers déjà copiés.

Si vous avez besoin d’un journal des fichiers au format txt, utilisez /log+:Files.log

Pratique si c'est média.

Il y a beaucoup plus de commutateurs sur TechNet


Pas beaucoup plus, j'ai inclus XO et en utilisant un fichier de sortie texte. Toujours bien de vérifier les travaux de copie. Ou si quelque chose ne va pas pour vérifier pourquoi. Son lecteur étant dégradé, le redémarrage d'un travail de copie avec XO ignorera les fichiers copiés.
jacojburger le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.