Macrium Reflect questions

"Art Todesco" schreef in bericht
...
Looking for some Macruim Reflect experts. I downloaded the free version
and attempted a image of the c drive. It is a 256G SSD with Windows 7 Pro
and all of the installed programs. I want to do a complete backup in case
the c drive gets corrupted or dies. I selected 'image' and ran the
program. The c SSD has 67G of data according to Windows. I put the image
file on a 1T 'backup drive' and it produced a file of 29G. I don't get
this. What's missing? I'd also like to test the backup file so that I
won't be doing useless backups every month. Is there a way to do this
without destroying my present c drive? I wish these programs were a bit
more user friendly!



Have you enabled intelligent sector copy? And compression high?
I don't know abot SSD's.

It's a great program and I've used it successfully for a long time.



--


|\ /|
| \/ |@rk
\../
\/os

Art Todesco wrote:
On 10/6/2015 2:03 PM, . . .winston wrote:
Art Todesco wrote on 10/06/2015 9:35 AM:

One other thing, in my mind, image and clone are the same thing. What's
the difference? I know clone is usually used when you want to put in an
SSD. You clone the original, write it to the SSD and then physically
swap out the original drive for the new SSD. I want to just have a good
image or clone of my c SSD so that if I get attacked by a virus or bad
adware, as I did earlier this year, I can revert back to the last
backup. To me, after reading Macrium's text, both should work, but
then, why have the option?

"Cloning copies the complete contents of one drive—the files, the
partition tables and the master boot record—to another: a simple, direct
duplicate. Imaging copies all of that to a single, very large file on
another drive. You can then restore the image back onto the existing
drive or onto a new one.


Typically, people use these techniques to back up the drive, or when
upgrading to a larger or faster drive. Both techniques will work for
each of these chores. But imaging usually makes more sense for a backup,
while cloning is the easiest choice for drive upgrades. "

Thanks again ... I figured it was something like that. I redid the
backup, shutting off compression, however, it still came out with a
rather substantial difference. The 68G from the SSD made a 46G file on
the backup drive. BTW, I also used the option to verify the saved data
and of course, as expected, took much longer. Is this difference in size
just the overhead of each original file now being, basically eliminated?
To me, the difference still seems large.


You can "mount" the partition inside the .mrimg file, and
use your favorite "dir" command to list the contents.

The best place to do such a comparison, would be Linux, but
of course then you couldn't mount the .mrimg.

Like many of these VHD-like technologies, there are "converters".
Typically, the body of the mrimg file is similar to the body
of a VHD. Just the header and trailer can be quite different.
I've had converter tools that are so efficient, they re-write
the file in place (keeping the sectors of the body and rewriting
by append and so on, the header and trailer). Such converters
can be finished in a matter of seconds, and change the file
type of the capture. A poorly written converter might decide
to rewrite the whole file (which has advantages in that the
output is independent of the input file, and does not affect it).

This article states that with Macrium 5 or later, conversion to
VHD ia built into the tool. So if you wanted the .mrimg (proprietary)
format in a more open format, you can convert to .vhd from
the menu. And from .vhd, many virtual hosting softwares can
convert to some other format if you needed it.

http://kb.macrium.com/KnowledgebaseArticle50005.aspx

The reason I have to suggest some of these routes, is because
of the difficulty in Windows, of finding a utility that
lists absolutely everything, even areas with "Accessed Denied"
error messages. That's why I head to Linux, when I want a reasonable
level of (forensic) assurance that I'm seeing everything, on both
the original partition, and on the "copy", whatever that
copy might be.

*******

Maybe simply mounting the .mrimg partition and using windirstat
on it, will help identify that the .mrimg does not have
a pagefile or a hiberfile. But I like to have tools and paths
that allow other methods to be used, just in case the
differences are "harder to spot". And the above is meant to
indicate you're not "trapped" by having a .mrimg in hand.
There was ways to export the data to other platforms if
need be.

Paul

In message , Alek
writes:
Ken1943 wrote on 10/5/2015 10:26 PM:
On Mon, 5 Oct 2015 20:27:56 -0400, Alek
wrote:

Ken1943 wrote on 10/5/2015 7:31 PM:
[]
They usually use compression. You really don't want a 67gig image
file.

Why not? What does one do with an image file, anyway?

It will restore a whole HDD.

How?

By using the separate boot CD you made the first time you used the
imaging software (-:. (Most - all, I think - imaging softwares offer the
option of making such a disc; if they don't, they're not really worth
bothering with, IMO.)

So, if your HD dies, you buy a new one, fit it, boot from the boot CD
(you may need to tweak the BIOS to let you), and invoke the option to
recreate the disc on the new HD from the image.

(I'm assuming you put the image on a separate, external, HD [or USB
stick, or whatever]; if you put it on the HD that's died, you're
screwed.)

I'd always make sure I knew how to boot from the CD, by doing a trial
run, i. e. tweaking the BIOS if necessary and actually booting from the
CD - just stop before restoring from the image of course; this also
makes sure (well, as sure as you can be) that the CD made properly. (The
CD probably boots a form of Linux, though it doesn't really matter -
it's a single-purpose OS, so you don't really need to know what it runs
underneath.) If you are using a USB stick or external USB drive for the
backup image, then it's also worth making sure the computer _when booted
from the CD_ can actually see the drive with the image on it (there's
usually an option to search for image files, or something like that).
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Reality television. It's eroding the ability of good scripted television to
survive. - Patrick Duffy in Radio Times 2-8 February 2013

In message , . . .winston
writes:
Art Todesco wrote on 10/06/2015 9:35 AM:

One other thing, in my mind, image and clone are the same thing. What's
the difference? I know clone is usually used when you want to put in an
SSD. You clone the original, write it to the SSD and then physically
swap out the original drive for the new SSD. I want to just have a good
image or clone of my c SSD so that if I get attacked by a virus or bad
adware, as I did earlier this year, I can revert back to the last
backup. To me, after reading Macrium's text, both should work, but
then, why have the option?

"Cloning copies the complete contents of one drive—the files, the
partition tables and the master boot record—to another: a simple,

With the advantage that you can put the cloned drive in straight away if
the source one dies. The disadvantage is that you can only backup one
drive per drive.

direct duplicate. Imaging copies all of that to a single, very large
file on another drive. You can then restore the image back onto the
existing drive or onto a new one.

You can indeed - _if_ you have the separate CD (or whatever) you made
the first time you made an image (and the system, booted from that CD,
can "see" the image file, on whatever medium you've put it). The
advantage, of course, is that you can image several drives - or the same
drive several times - on whatever backup medium you use. (Even more than
you think: most imaging software has options [a] to only include in the
image the used space from the disc being imaged rather than all of it,
[b] omit even from that any files that it knows Windows will just make
again anyway which tend to be big files like the page and hibernating
files, and [c] compress the files [though some of us turn that off].)

Typically, people use these techniques to back up the drive, or when
upgrading to a larger or faster drive. Both techniques will work for
each of these chores. But imaging usually makes more sense for a
backup, while cloning is the easiest choice for drive upgrades. "

Yes, if you're just moving to a bigger/faster/whatever drive from one
that works, cloning is simpler and (probably, if it skips unused space)
faster.

--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Reality television. It's eroding the ability of good scripted television to
survive. - Patrick Duffy in Radio Times 2-8 February 2013

On Mon, 05 Oct 2015 19:05:21 -0400 "Paul" wrote in
article
(I always turn compression off, because that's
the kind of guy I am...)

Why? All LZW implementations I know of compress in blocks so as not to be
susceptible to a single-bit error's ruining everything downstream--just
to the end of the block. (Not good but not necessarily catastrophic) I
turn it off because it doesn't make much difference other than to burn
cycles. The largest files are usually already compressed anyway and may
actually grow if a naive algorithm tries to shrink them.

Jason wrote:
On Mon, 05 Oct 2015 19:05:21 -0400 "Paul" wrote in
article
(I always turn compression off, because that's
the kind of guy I am...)

Why? All LZW implementations I know of compress in blocks so as not to be
susceptible to a single-bit error's ruining everything downstream--just
to the end of the block. (Not good but not necessarily catastrophic) I
turn it off because it doesn't make much difference other than to burn
cycles. The largest files are usually already compressed anyway and may
actually grow if a naive algorithm tries to shrink them.

I leave compression as a "Post-backup" step.

For short term backups (backup while experimenting),
there's no reason to apply compression to those.

For long term backups (the one on my 3TB drive), it
makes more sense to compress those. The compressor
in that case is multithreaded, and the block size is limited
to the size used by a thread.

And I don't even want to guess what the error multiplication
is like, as files are not stored contiguous, instead
clusters are stored, and if your files are fragmented, then
a lost block could affect fragments of various files. I doubt
it would be much fun to piece together again.

If you thought that sort of loss was feasible (a characteristic
of the storage device), you could always apply QuickPAR to the thing.
And store some parity blocks. But I can't say I've run into any
discussion threads where anyone is doing that.

Paul

On Tue, 06 Oct 2015 13:58:33 -0400, Paul wrote:

If you clone a 500GB drive onto a second 500GB drive,
then 500GB of space is taken up. Your recovery plan
could use "clones" as its primary mechanism. But, it
isn't all that efficient.

Drive #1 --- Drive #2 can be used as a disaster recovery plan...
Is an inefficient means of doing so...

If the temporaryfile.mrimg is 67GB, and restores a 500GB
Drive #2, then that is more space efficient. I have images
of all my hard drives, stored on a 3TB drive. And I can do that,
because not all the drives are absolutely full of data. And
if you use compression on the images

temporaryfile.mrimg.7z
temporaryfile.mrimg.rar

then that tends to save more space than the compression
option in Macrium would. I do my compression steps
(if used, scenario dependent), on a second computer.
This separates the compression step, from the backup
step. Compression is so computationally difficult, it
costs me $1 of electricity, to compress all the mrimg
files on my 3TB drive. And it takes all day. It used
to take all week, until I put a machine together just
for the purpose of doing compression a bit faster.

That's some strange behavior. ;-)

You want compression, but you don't want compression on the fly, or you
don't want compression to be performed by the backup program. Strange.

--

Char Jackson

Char Jackson wrote:
On Tue, 06 Oct 2015 13:58:33 -0400, Paul wrote:

If you clone a 500GB drive onto a second 500GB drive,
then 500GB of space is taken up. Your recovery plan
could use "clones" as its primary mechanism. But, it
isn't all that efficient.

Drive #1 --- Drive #2 can be used as a disaster recovery plan...
Is an inefficient means of doing so...

If the temporaryfile.mrimg is 67GB, and restores a 500GB
Drive #2, then that is more space efficient. I have images
of all my hard drives, stored on a 3TB drive. And I can do that,
because not all the drives are absolutely full of data. And
if you use compression on the images

temporaryfile.mrimg.7z
temporaryfile.mrimg.rar

then that tends to save more space than the compression
option in Macrium would. I do my compression steps
(if used, scenario dependent), on a second computer.
This separates the compression step, from the backup
step. Compression is so computationally difficult, it
costs me $1 of electricity, to compress all the mrimg
files on my 3TB drive. And it takes all day. It used
to take all week, until I put a machine together just
for the purpose of doing compression a bit faster.

That's some strange behavior. ;-)

You want compression, but you don't want compression on the fly, or you
don't want compression to be performed by the backup program. Strange.


I explained in another post, the reasoning.

1) Compression by the tool isn't very good. It might be LZO or LZW.
It wastes time (I want any backup to be finished as soon as possible).
And doing two compression steps, in my testing, isn't a good approach
either.

2) Now that the backup is made (uncompressed), it's time to look
at the purpose. If the backup was made, so that a dangerous
experiment could be carried out on C:, then the backup file
(.mrimg) will not be compressed. I might only need the backup
file for ten minutes, in a case like that. Think System Restore
on steroids.

3) If the backup is intended for long term usage (protection
against hard drive failure, protection against Sality or
Cryptolocker), the backup file is compressed and put on the
3TB drive. The 3TB drive is then disconnected from the computer.
By doing just one compression step, you get the best compression
ratio. Some compression programs have pre-filters, which recognize
things like PE32 or PE64 and re-code them. And that saves a little
more space. The best compression is if you compress just the one
time - you get the highest ratio, and the processing time might
be a bit better.

I don't like the main machine to be tied up with maintenance
if I can help it. Running Macrium is unavoidable, but getting
it to complete as quickly as possible, means post-processing
can be done somewhere else - if it is required/needed at the
time.

Paul

On Wed, 07 Oct 2015 10:19:59 -0400, Paul wrote:

Char Jackson wrote:
On Tue, 06 Oct 2015 13:58:33 -0400, Paul wrote:

If you clone a 500GB drive onto a second 500GB drive,
then 500GB of space is taken up. Your recovery plan
could use "clones" as its primary mechanism. But, it
isn't all that efficient.

Drive #1 --- Drive #2 can be used as a disaster recovery plan...
Is an inefficient means of doing so...

If the temporaryfile.mrimg is 67GB, and restores a 500GB
Drive #2, then that is more space efficient. I have images
of all my hard drives, stored on a 3TB drive. And I can do that,
because not all the drives are absolutely full of data. And
if you use compression on the images

temporaryfile.mrimg.7z
temporaryfile.mrimg.rar

then that tends to save more space than the compression
option in Macrium would. I do my compression steps
(if used, scenario dependent), on a second computer.
This separates the compression step, from the backup
step. Compression is so computationally difficult, it
costs me $1 of electricity, to compress all the mrimg
files on my 3TB drive. And it takes all day. It used
to take all week, until I put a machine together just
for the purpose of doing compression a bit faster.

That's some strange behavior. ;-)

You want compression, but you don't want compression on the fly, or you
don't want compression to be performed by the backup program. Strange.


I explained in another post, the reasoning.

1) Compression by the tool isn't very good. It might be LZO or LZW.
It wastes time (I want any backup to be finished as soon as possible).
And doing two compression steps, in my testing, isn't a good approach
either.

2) Now that the backup is made (uncompressed), it's time to look
at the purpose. If the backup was made, so that a dangerous
experiment could be carried out on C:, then the backup file
(.mrimg) will not be compressed. I might only need the backup
file for ten minutes, in a case like that. Think System Restore
on steroids.

3) If the backup is intended for long term usage (protection
against hard drive failure, protection against Sality or
Cryptolocker), the backup file is compressed and put on the
3TB drive. The 3TB drive is then disconnected from the computer.
By doing just one compression step, you get the best compression
ratio. Some compression programs have pre-filters, which recognize
things like PE32 or PE64 and re-code them. And that saves a little
more space. The best compression is if you compress just the one
time - you get the highest ratio, and the processing time might
be a bit better.

I don't like the main machine to be tied up with maintenance
if I can help it. Running Macrium is unavoidable, but getting
it to complete as quickly as possible, means post-processing
can be done somewhere else - if it is required/needed at the
time.

I hear what you're saying, but I remain completely unconvinced. In my
experience, compression during backup is virtually free in terms of
additional processing time. Disk I/O appears to be the bottleneck, not on
the fly compression. Then again, I'm not worried about wringing every last
byte out of it, considering the low cost of storage these days. One of WD's
6TB drives has been hovering around $200 all summer, which is an excellent
deal in itself, but also serves to put downward pressure on smaller drives.

--

Char Jackson

Char Jackson wrote:
On Wed, 07 Oct 2015 10:19:59 -0400, Paul wrote:

Char Jackson wrote:
On Tue, 06 Oct 2015 13:58:33 -0400, Paul wrote:

If you clone a 500GB drive onto a second 500GB drive,
then 500GB of space is taken up. Your recovery plan
could use "clones" as its primary mechanism. But, it
isn't all that efficient.

Drive #1 --- Drive #2 can be used as a disaster recovery plan...
Is an inefficient means of doing so...

If the temporaryfile.mrimg is 67GB, and restores a 500GB
Drive #2, then that is more space efficient. I have images
of all my hard drives, stored on a 3TB drive. And I can do that,
because not all the drives are absolutely full of data. And
if you use compression on the images

temporaryfile.mrimg.7z
temporaryfile.mrimg.rar

then that tends to save more space than the compression
option in Macrium would. I do my compression steps
(if used, scenario dependent), on a second computer.
This separates the compression step, from the backup
step. Compression is so computationally difficult, it
costs me $1 of electricity, to compress all the mrimg
files on my 3TB drive. And it takes all day. It used
to take all week, until I put a machine together just
for the purpose of doing compression a bit faster.
That's some strange behavior. ;-)

You want compression, but you don't want compression on the fly, or you
don't want compression to be performed by the backup program. Strange.

I explained in another post, the reasoning.

1) Compression by the tool isn't very good. It might be LZO or LZW.
It wastes time (I want any backup to be finished as soon as possible).
And doing two compression steps, in my testing, isn't a good approach
either.

2) Now that the backup is made (uncompressed), it's time to look
at the purpose. If the backup was made, so that a dangerous
experiment could be carried out on C:, then the backup file
(.mrimg) will not be compressed. I might only need the backup
file for ten minutes, in a case like that. Think System Restore
on steroids.

3) If the backup is intended for long term usage (protection
against hard drive failure, protection against Sality or
Cryptolocker), the backup file is compressed and put on the
3TB drive. The 3TB drive is then disconnected from the computer.
By doing just one compression step, you get the best compression
ratio. Some compression programs have pre-filters, which recognize
things like PE32 or PE64 and re-code them. And that saves a little
more space. The best compression is if you compress just the one
time - you get the highest ratio, and the processing time might
be a bit better.

I don't like the main machine to be tied up with maintenance
if I can help it. Running Macrium is unavoidable, but getting
it to complete as quickly as possible, means post-processing
can be done somewhere else - if it is required/needed at the
time.

I hear what you're saying, but I remain completely unconvinced. In my
experience, compression during backup is virtually free in terms of
additional processing time. Disk I/O appears to be the bottleneck, not on
the fly compression. Then again, I'm not worried about wringing every last
byte out of it, considering the low cost of storage these days. One of WD's
6TB drives has been hovering around $200 all summer, which is an excellent
deal in itself, but also serves to put downward pressure on smaller drives.


I don't have quite as much storage space as you do :-)

And my collection of drives is pretty ratty. The number
of drives in good shape, means I use compression for my
backups.

I generally average about two drives purchased per year,
and that's to replace boot drives made by Seagate. I don't
buy backup-sized drives all that often.

Paul

Char Jackson wrote:
On Wed, 07 Oct 2015 10:19:59 -0400, Paul wrote:

Char Jackson wrote:
On Tue, 06 Oct 2015 13:58:33 -0400, Paul wrote:

If you clone a 500GB drive onto a second 500GB drive,
then 500GB of space is taken up. Your recovery plan
could use "clones" as its primary mechanism. But, it
isn't all that efficient.

Drive #1 --- Drive #2 can be used as a disaster recovery plan...
Is an inefficient means of doing so...

If the temporaryfile.mrimg is 67GB, and restores a 500GB
Drive #2, then that is more space efficient. I have images
of all my hard drives, stored on a 3TB drive. And I can do that,
because not all the drives are absolutely full of data. And
if you use compression on the images

temporaryfile.mrimg.7z
temporaryfile.mrimg.rar

then that tends to save more space than the compression
option in Macrium would. I do my compression steps
(if used, scenario dependent), on a second computer.
This separates the compression step, from the backup
step. Compression is so computationally difficult, it
costs me $1 of electricity, to compress all the mrimg
files on my 3TB drive. And it takes all day. It used
to take all week, until I put a machine together just
for the purpose of doing compression a bit faster.

That's some strange behavior. ;-)

You want compression, but you don't want compression on the fly, or you
don't want compression to be performed by the backup program. Strange.


I explained in another post, the reasoning.

1) Compression by the tool isn't very good. It might be LZO or LZW.
It wastes time (I want any backup to be finished as soon as possible).
And doing two compression steps, in my testing, isn't a good approach
either.

2) Now that the backup is made (uncompressed), it's time to look
at the purpose. If the backup was made, so that a dangerous
experiment could be carried out on C:, then the backup file
(.mrimg) will not be compressed. I might only need the backup
file for ten minutes, in a case like that. Think System Restore
on steroids.

3) If the backup is intended for long term usage (protection
against hard drive failure, protection against Sality or
Cryptolocker), the backup file is compressed and put on the
3TB drive. The 3TB drive is then disconnected from the computer.
By doing just one compression step, you get the best compression
ratio. Some compression programs have pre-filters, which recognize
things like PE32 or PE64 and re-code them. And that saves a little
more space. The best compression is if you compress just the one
time - you get the highest ratio, and the processing time might
be a bit better.

I don't like the main machine to be tied up with maintenance
if I can help it. Running Macrium is unavoidable, but getting
it to complete as quickly as possible, means post-processing
can be done somewhere else - if it is required/needed at the
time.

I hear what you're saying, but I remain completely unconvinced. In my
experience, compression during backup is virtually free in terms of
additional processing time. Disk I/O appears to be the bottleneck, not on
the fly compression. Then again, I'm not worried about wringing every last
byte out of it, considering the low cost of storage these days.

My thoughts exactly. And, KISS.

--
Mike Barnes
Cheshire, England

On Wed, 07 Oct 2015 10:19:59 -0400, Paul wrote:
Char Jackson wrote:
[quoted text muted]

You want compression, but you don't want compression on the fly, or you
don't want compression to be performed by the backup program. Strange.


I explained in another post, the reasoning.

1) Compression by the tool isn't very good.


97 GB to 24 "isn't very good"? Wowsers! I guess I'm too easily
satisfied.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...

On 08/10/2015 02:09, Stan Brown wrote:
I guess I'm too easily
satisfied.


No need to guess. You are too stupid to understand anything.

Stan Brown wrote:
On Wed, 07 Oct 2015 10:19:59 -0400, Paul wrote:
Char Jackson wrote:
[quoted text muted]

You want compression, but you don't want compression on the fly, or you
don't want compression to be performed by the backup program. Strange.

I explained in another post, the reasoning.

1) Compression by the tool isn't very good.


97 GB to 24 "isn't very good"? Wowsers! I guess I'm too easily
satisfied.


OK, try the following experiment.

1) Generate Macrium backup uncompressed.
2) Install 7ZIP.
3) Click the .mrimg file, select "Add to Archive"
from the right-click menu, which opens 7ZIP.
Select 7Z format, set compression to "Ultra".
4) When the final file is produced, now good is it now ?

Of course, you don't have to do the experiment,
as there is likely to be a chart around somewhere.

http://i.stack.imgur.com/b6P7d.png

Arithmetic coders, the ones on the right of the graph,
do the best job, but they're really not that much better.
It all depends on whether the result "just barely fits"
on some storage device, whether it's a big win for you.
In my case, maybe I save 300GB to 500GB using one from
the right of the chart.

https://en.wikipedia.org/wiki/Data_compression

GZIP is a pretty good compromise. Even better, is the
PIGZ multithreaded compressor. The best version of PIGZ
is the Linux version, as the Windows port, I don't think
the header information is fixed on it yet. Regular GZIP
might use only one core, whereas PIGZ uses more than
one core. So if you need compression in a hurry, and
the file is big enough, it might pay off to temporarily
boot up Linux and do it.

7Z compression in 7ZIP is capable of using a lot of cores
on the CPU, but it's a pretty miserable algorithm in terms
of how hard the CPU has to work. To get the best performance
on Win8 or Win10, tell the program you have twice as many
cores as are actually present. That cuts down on the "CPU
reserve" those OSes hold back.

Paul

On 05/10/2015 6:36 PM, Art Todesco wrote:
Looking for some Macruim Reflect experts. I downloaded the free version
and attempted a image of the c drive. It is a 256G SSD with Windows 7
Pro and all of the installed programs. I want to do a complete backup in
case the c drive gets corrupted or dies. I selected 'image' and ran the
program. The c SSD has 67G of data according to Windows. I put the image
file on a 1T 'backup drive' and it produced a file of 29G. I don't get
this. What's missing? I'd also like to test the backup file so that I
won't be doing useless backups every month. Is there a way to do this
without destroying my present c drive? I wish these programs were a bit
more user friendly!

It gets compressed.

Yousuf Khan