If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
Chkdsk or what???
On Tue, 25 Sep 2018 12:20:40 -0500, Char Jackson
wrote: On Tue, 11 Sep 2018 08:31:15 -0400, Paul wrote: Macrium uses smart copy for both backups and cloning. It does *not* copy all the sectors. If you have files recently deleted, you would like to do an undelete on them, then running Macrium in clone or backup, will *not* bring over the materials necessary for undelete to work. Things that are deleted, are not recorded. A Macrium clone or a Macrium backup, is *not* a forensic copy. Not by any stretch of the imagination. If you have 20GB of files on a 500GB partition, Macrium does 20GB of writes for either "clone" or "backup". The other 480GB are not touched. I have tested Macrium in the past, ticked some box that claimed to be closer to traditional "dd" style cloning, and it *still* only did 20GB of writes. And you just know your undelete information is being tossed into the drink. I haven't tested Macrium in that way and have no reason to doubt you, but that's NOT what the Reflect GUI would have you believe. The two options a - Intelligent Sector Copy (Recommended) Copies only disk sectors used by the file system. Windows pagefile and suspend to disk (hibernation) are not copied. This reduces the image size and backup time. - Make an exact copy of the partition(s). Partitions include unused sectors therefore forensic examination of the partition(s) remain unchanged. Deleted files may be recovered for example. Are they lying about that second option? Good news - Macrium's second option above, "Make an exact copy of the partition(s)", seems to do exactly that. They're telling the truth. Macrium Reflect Free v7.1.3317 Recuva 1.5.2 Before the backup, Macrium said the partition was 476.93GB, with 137.64 used and 339.30 free. After the backup, Macrium says the image is 476.93GB, with 131.96 used and 344.97 free, with the difference being about the size of the Windows swapfile. Before the backup, Windows said the volume (C:\) had a capacity of 476GB, with 138GB used and 338GB free. After the backup, with the image mounted as G;\, Windows says it has a capacity of 476GB, with 131GB used and 344GB free. Interestingly, checking the properties of the image just prior to mounting it, Macrium includes the note "Intelligent Sector Copy: No", just as I had expected. Using an older copy of Recuva that I had lying around, I ran a normal (not 'deep') scan. Recuva said it found 2490 deleted files in 20.41 seconds. I picked the first 10 and successfully recovered them. Next, I picked another 10 at random and successfully recovered each of them, as well. *** So Paul, I don't know what to tell you. The Macrium version that you tested could have had a bug that ignored your choice to "Make an exact copy of the partition(s)", but I think the more likely sequence of events was that you were poking around in the GUI, examining every available option, and at some point you backed out of somewhere and inadvertently reset the backup options to their defaults. Bottom line, this feature appears to work exactly like it should. -- Char Jackson |
Ads |
#17
|
|||
|
|||
Chkdsk or what???
Char Jackson wrote:
On Tue, 25 Sep 2018 12:20:40 -0500, Char Jackson wrote: On Tue, 11 Sep 2018 08:31:15 -0400, Paul wrote: Macrium uses smart copy for both backups and cloning. It does *not* copy all the sectors. If you have files recently deleted, you would like to do an undelete on them, then running Macrium in clone or backup, will *not* bring over the materials necessary for undelete to work. Things that are deleted, are not recorded. A Macrium clone or a Macrium backup, is *not* a forensic copy. Not by any stretch of the imagination. If you have 20GB of files on a 500GB partition, Macrium does 20GB of writes for either "clone" or "backup". The other 480GB are not touched. I have tested Macrium in the past, ticked some box that claimed to be closer to traditional "dd" style cloning, and it *still* only did 20GB of writes. And you just know your undelete information is being tossed into the drink. I haven't tested Macrium in that way and have no reason to doubt you, but that's NOT what the Reflect GUI would have you believe. The two options a - Intelligent Sector Copy (Recommended) Copies only disk sectors used by the file system. Windows pagefile and suspend to disk (hibernation) are not copied. This reduces the image size and backup time. - Make an exact copy of the partition(s). Partitions include unused sectors therefore forensic examination of the partition(s) remain unchanged. Deleted files may be recovered for example. Are they lying about that second option? Good news - Macrium's second option above, "Make an exact copy of the partition(s)", seems to do exactly that. They're telling the truth. Macrium Reflect Free v7.1.3317 Recuva 1.5.2 Before the backup, Macrium said the partition was 476.93GB, with 137.64 used and 339.30 free. After the backup, Macrium says the image is 476.93GB, with 131.96 used and 344.97 free, with the difference being about the size of the Windows swapfile. If I understand you correctly, this is *not* "an exact copy of the partition", because if it was, there would be *no* differences, i.e. also no difference caused by the swapfile. I think the inexact copy is a result of this: Before the backup, Windows said the volume (C:\) had a capacity of 476GB, with 138GB used and 338GB free. After the backup, with the image mounted as G;\, Windows says it has a capacity of 476GB, with 131GB used and 344GB free. I think one cannot make an exact copy of C:, because C: is needed for the Volume Shadow Copy snapshot which Macrium Reflect makes of the to be backed up partition. IOW, MR needs C: for its snapshot of C:, so it *does* change C: during the image backup, so it *cannot* make an exact copy. (This assumes that snapshots always reside on C:. I do not know if that assumption is correct.) It would be interesting if you could "Make an exact copy of the partition" of a non-C: partition, preferably one which is not in use or is even 'unmounted' (i.e. doesn't have a drive letter) and then see if there are indeed *no* differences between the partition and its image. Interestingly, checking the properties of the image just prior to mounting it, Macrium includes the note "Intelligent Sector Copy: No", just as I had expected. Using an older copy of Recuva that I had lying around, I ran a normal (not 'deep') scan. Recuva said it found 2490 deleted files in 20.41 seconds. I picked the first 10 and successfully recovered them. Next, I picked another 10 at random and successfully recovered each of them, as well. *** So Paul, I don't know what to tell you. The Macrium version that you tested could have had a bug that ignored your choice to "Make an exact copy of the partition(s)", but I think the more likely sequence of events was that you were poking around in the GUI, examining every available option, and at some point you backed out of somewhere and inadvertently reset the backup options to their defaults. Bottom line, this feature appears to work exactly like it should. |
#18
|
|||
|
|||
Chkdsk or what???
On 1 Oct 2018 15:40:59 GMT, Frank Slootweg
wrote: Char Jackson wrote: On Tue, 25 Sep 2018 12:20:40 -0500, Char Jackson wrote: On Tue, 11 Sep 2018 08:31:15 -0400, Paul wrote: Macrium uses smart copy for both backups and cloning. It does *not* copy all the sectors. If you have files recently deleted, you would like to do an undelete on them, then running Macrium in clone or backup, will *not* bring over the materials necessary for undelete to work. Things that are deleted, are not recorded. A Macrium clone or a Macrium backup, is *not* a forensic copy. Not by any stretch of the imagination. If you have 20GB of files on a 500GB partition, Macrium does 20GB of writes for either "clone" or "backup". The other 480GB are not touched. I have tested Macrium in the past, ticked some box that claimed to be closer to traditional "dd" style cloning, and it *still* only did 20GB of writes. And you just know your undelete information is being tossed into the drink. I haven't tested Macrium in that way and have no reason to doubt you, but that's NOT what the Reflect GUI would have you believe. The two options a - Intelligent Sector Copy (Recommended) Copies only disk sectors used by the file system. Windows pagefile and suspend to disk (hibernation) are not copied. This reduces the image size and backup time. - Make an exact copy of the partition(s). Partitions include unused sectors therefore forensic examination of the partition(s) remain unchanged. Deleted files may be recovered for example. Are they lying about that second option? Good news - Macrium's second option above, "Make an exact copy of the partition(s)", seems to do exactly that. They're telling the truth. Macrium Reflect Free v7.1.3317 Recuva 1.5.2 Before the backup, Macrium said the partition was 476.93GB, with 137.64 used and 339.30 free. After the backup, Macrium says the image is 476.93GB, with 131.96 used and 344.97 free, with the difference being about the size of the Windows swapfile. If I understand you correctly, this is *not* "an exact copy of the partition", because if it was, there would be *no* differences, i.e. also no difference caused by the swapfile. I think the inexact copy is a result of this: Before the backup, Windows said the volume (C:\) had a capacity of 476GB, with 138GB used and 338GB free. After the backup, with the image mounted as G;\, Windows says it has a capacity of 476GB, with 131GB used and 344GB free. I think one cannot make an exact copy of C:, because C: is needed for the Volume Shadow Copy snapshot which Macrium Reflect makes of the to be backed up partition. IOW, MR needs C: for its snapshot of C:, so it *does* change C: during the image backup, so it *cannot* make an exact copy. (This assumes that snapshots always reside on C:. I do not know if that assumption is correct.) It would be interesting if you could "Make an exact copy of the partition" of a non-C: partition, preferably one which is not in use or is even 'unmounted' (i.e. doesn't have a drive letter) and then see if there are indeed *no* differences between the partition and its image. I'm already satisfied, but by all means go ahead and do that additional testing. My data drives are all 2TB and 4TB, partitioned as single volumes and each about 93% full, so it would be inconvenient to try to image one of those. If I get really bored, I could get an empty 2TB drive out and create a small-ish partition for the test, but I think the issue is already settled. I was primarily addressing Paul's earlier test results, where he wound up with what was supposed to be an exact copy, but it was way too small to the point where deleted files had no chance to be restored. My Windows drive was the best candidate for that test since it's by far my smallest drive. -- Char Jackson |
#19
|
|||
|
|||
Chkdsk or what???
Char Jackson wrote:
On 1 Oct 2018 15:40:59 GMT, Frank Slootweg wrote: Char Jackson wrote: On Tue, 25 Sep 2018 12:20:40 -0500, Char Jackson wrote: On Tue, 11 Sep 2018 08:31:15 -0400, Paul wrote: Macrium uses smart copy for both backups and cloning. It does *not* copy all the sectors. If you have files recently deleted, you would like to do an undelete on them, then running Macrium in clone or backup, will *not* bring over the materials necessary for undelete to work. Things that are deleted, are not recorded. A Macrium clone or a Macrium backup, is *not* a forensic copy. Not by any stretch of the imagination. If you have 20GB of files on a 500GB partition, Macrium does 20GB of writes for either "clone" or "backup". The other 480GB are not touched. I have tested Macrium in the past, ticked some box that claimed to be closer to traditional "dd" style cloning, and it *still* only did 20GB of writes. And you just know your undelete information is being tossed into the drink. I haven't tested Macrium in that way and have no reason to doubt you, but that's NOT what the Reflect GUI would have you believe. The two options a - Intelligent Sector Copy (Recommended) Copies only disk sectors used by the file system. Windows pagefile and suspend to disk (hibernation) are not copied. This reduces the image size and backup time. - Make an exact copy of the partition(s). Partitions include unused sectors therefore forensic examination of the partition(s) remain unchanged. Deleted files may be recovered for example. Are they lying about that second option? Good news - Macrium's second option above, "Make an exact copy of the partition(s)", seems to do exactly that. They're telling the truth. Macrium Reflect Free v7.1.3317 Recuva 1.5.2 Before the backup, Macrium said the partition was 476.93GB, with 137.64 used and 339.30 free. After the backup, Macrium says the image is 476.93GB, with 131.96 used and 344.97 free, with the difference being about the size of the Windows swapfile. If I understand you correctly, this is *not* "an exact copy of the partition", because if it was, there would be *no* differences, i.e. also no difference caused by the swapfile. I think the inexact copy is a result of this: Before the backup, Windows said the volume (C:\) had a capacity of 476GB, with 138GB used and 338GB free. After the backup, with the image mounted as G;\, Windows says it has a capacity of 476GB, with 131GB used and 344GB free. I think one cannot make an exact copy of C:, because C: is needed for the Volume Shadow Copy snapshot which Macrium Reflect makes of the to be backed up partition. IOW, MR needs C: for its snapshot of C:, so it *does* change C: during the image backup, so it *cannot* make an exact copy. (This assumes that snapshots always reside on C:. I do not know if that assumption is correct.) It would be interesting if you could "Make an exact copy of the partition" of a non-C: partition, preferably one which is not in use or is even 'unmounted' (i.e. doesn't have a drive letter) and then see if there are indeed *no* differences between the partition and its image. I'm already satisfied, but by all means go ahead and do that additional testing. My data drives are all 2TB and 4TB, partitioned as single volumes and each about 93% full, so it would be inconvenient to try to image one of those. If I get really bored, I could get an empty 2TB drive out and create a small-ish partition for the test, but I think the issue is already settled. I was primarily addressing Paul's earlier test results, where he wound up with what was supposed to be an exact copy, but it was way too small to the point where deleted files had no chance to be restored. My Windows drive was the best candidate for that test since it's by far my smallest drive. I was running something in the last couple days, and the time taken was consistent with doing sector-by-sector copying. The issue seems to be fixed, likely in the Version 6 copies I run around here now. But I did observe the setting being ignored on an older version of Macrium. It's physically impossible to make a sector by sector copy of one of my 500GB drives in 10 minutes. Only an intelligent copy (considering the quantity of unerased files) happens in ten minutes. I could tell from the execution time, that I'd been cheated with that version. A user should be able to guesstimate there is dishonesty just based on time. As the difference can be striking. It would be interesting to see what Recuva can find in a restored Intelligent Copy case. To run it, you'd 1) Make backup of drive using Intelligent Copy. 2) Use "diskpart.exe" in Windows, select the drive, do a "Clean All". This overwrites every sector with zeros. You want a clean platform for the restore area. 3) Now, do a Macrium Restore from the Intelligent Copy bsckup. 4) Recuva should find nothing besides visible files. There shouldn't be any files to recover. The $MFT can have a file name entry, with the byte flipped that says the file is present. A recovery routine can flip the byte back (in the "unerase sense"), but the content of the recovered file(s) would be zeros. An image editor would not be able to open a recovered JPG because there would be nothing inside it. Paul |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|