Macrium scheduling

VanguardLH wrote:

Terry Pinnell wrote:

You're running G-F-S, yes? How much capacity have you allocated for your images in
total?

Reflect images my C: drive (OS + apps + data). I move data to drive D:
that I don't want in the backups occupying disk space, because it is
replaceable or a copy stored elsewhere. C: is a 1TB NVMe SSD, but only
103GB is currently used.

My GFS is monthly full, weekly differential, and daily incrementals.
Retention is: 26 weeks for fulls (monthly), 5 weeks for differentials
(weekly), and 14 days for incrementals (dailies).

The internal D: drive 2TB HDD stores the backup images, program exported
configs/backups, and some rather large data files that don't need to be
in the backups (and why they're on the same drive as the backups which
you wouldn't do if they were in the backups). For example, a couple
versions of WSUSoffline are on D: to save all the MS updates for Win7,
Office 2016/2019, and Win10.

C: SSD drive: 103GB used (of 1TB)
D: HDD drive: 546GB used (of 2TB)
410GB for Reflect image backups (*)
13GB for wsusoffline (only have 1 copy now)
100GB for some large files
E: USB drive: 619GB used (of 2TB)
410GB for copies of Reflect image backups
100GB for copies of some of the large files
9GB for a copy of C:\Downloads (**)

(*) Includes a 70GB folder for Win7 full image taken before wiping and
a fresh install of Win10, just in case I need data from that old setup.
(**) Not the default Downloads folder in Win10 (which is under my
account profile folder and used only for temporary downloads).
C:\DOWNLOADS is where I store all my downloads for all programs, copied
to E: (USB) and occasionally copied to a 64GB USB flash drive.

For my Win10 desktop, image backups only go back to Aug 2019, because
that's when I built the new box. 6 months retention means the old ones
will start rolling out around Jan-Feb 2020. For now, I should have
plenty of free space to accomodate the later backups (along with the
other files I'm saving on the "backup" drives). If I went to a year's
retention, I'd be looking to replace the 2TB drives with 4TB drives, or
larger, depending on my budget at the time. Or, if I consumed a lot
more space on the 1TB NVMe SSD, I'd have to get bigger backup drives.

Note: Not all the image backup files for Reflect are for the scheduled
backup jobs. Occasionally I create an image backup before some change,
like an incremental if I do MS updates in the evening (since there
wouldv'e been an incremental that day early in the morning), or a
differential or full depending on the magnitude of the change for which
I want an escape route for recovery. So, besides the scheduled backups,
there are a few manual backups saved on D: (and then sync'ed to E: for a
2nd copy of the backups).

My old boxes go to family to upgrade their hardware. So, as yet, I
haven't had a 2nd box at home to use to save backup files via FTP. That
would be safer for the backup copies than a USB drive (which has to be
connected and powered on all the time to do the backup file sync to the
USB drive after the scheduled backup jobs). Reflect has its Image
Guardian which acts like a rootkit by injecting its driver in the OS
file I/O APIs to protect against writes and deletes of the backup files
(but doesn't prevent reading them).

Image Guardian helps a bit against ransomware for either the backup
files on my D: "backup" internal HDD drive and the backup of backup
files on the E: USB HDD drive. However, if I can figure out how to
workaround Image Guardian, I'm sure malware can, too. I discussed the
window of opportunity for malware to get past Image Guardian with
Macrium, they agreed, but they weren't interested in a more thorough
protection scheme. They added something to bolster their backup
software against most ransomware, and it suffices for that.

Anything that is currently mounted can be found by ransomware or
malware. Hell, all it has to do is run diskpart and run "list volume".
Drive letters are not required to get at partitions. Acronis, Paragon,
and another (I forget which) can store backups in "hidden" partitions:
the partition type number is non-standard, so standard disk tools should
leave it alone, and no drive letter is assigned (which is the "hiding"
part), but those backup programs can still access the partitions to
write and read their backup files from there. Not assigning a drive
letter to a partition doesn't block access to the partition, so it's a
weak anti-ransomware protection scheme, but better than nothing.
Programs can use mount points. Humans have been trained to recognize
drive letters.

With backup files getting copied to an FTP server, malware can't reach
those backups because they won't know the login credentials for the
account under which the backups get uploaded to the FTP host, and other
modes of access would be locked out. For scheduled backup to run and
then send a copy to the FTP server, the login credentials would have to
be stored but be secure to prevent malware from finding the login
credentials. FTPS would be needed to secure the login credentials
during transit to prevent sniffing by malware.

Thanks. If I change my simple 'weekly Fulls' to a G-F-S method, your configuration
details will prove very helpful. Especially as you have actually *restored* on
several occasions, which I hope I can continue to avoid!

Terry, East Grinstead, UK

Terry Pinnell wrote:

If I change my simple 'weekly Fulls' to a G-F-S method, your
configuration details will prove very helpful. Especially as you have
actually *restored* on several occasions, which I hope I can continue
to avoid!

But if you never restore, you don't know if the backup chain is okay.
The backup will, if the option is enabled, do a hash on the backed up
files against a hash of the current files on the drive(s), but that's is
not the same as actually reading the files out of the .mrimg backup
files to make sure they work. Some folks will restore to a spare
partition to check they can read from the backup files to do a restore.

I probably do a restore about once a month usually because it is far
easier to restore all registry or file states to eradicate software than
to run the installer (which are never clean) and having to hunt for
remnant registry entries and files to delete (and some registry entries
are so buried in deep levels with restrictive permissions which won't
recurse to subkeys that it can take a long time to delete a registry
key). regedit.exe doesn't show all of the registry, either.

Some MS updates have royally ****ed over a lot of users. I haven't been
hit, so far, but that doesn't discount the tribulations that other users
have incurred due to MS updates. Since Microsoft is pushing them out
during the month and every 6 months for the major updates, I still want
to save a manually instigated backup image before applying any updates
to Windows. For apps, I don't bother saving a backup before updating
them, because they are easy 'nuff to eradicate, reinstall fresh, and
have far fewer updates to get up to date on the apps.

Terry Pinnell wrote:

Thanks. If I change my simple 'weekly Fulls' to a G-F-S method, your configuration
details will prove very helpful. Especially as you have actually *restored* on
several occasions, which I hope I can continue to avoid!

Terry, East Grinstead, UK

You can run "Verify" on a .mrimg file. I like the option
because of the low amount of labor on my part, to run it.

You can also mount the partitions inside the .mrimg
using Macrium. If you backed up C:, you can mount
the backup partition as W: , then run a comparison
utility against the files, to see if they have the
same checksum.

For example, hashdeep could generate checksums for a tree.
Then you can tell whether the files on C: have changed,
with respect to the backup version. If using hashdeep with
a Windows 10 partition, there are a number of optional parameters
necessary for the run to finish without jamming up (reparse
points, named pipes, and other file system features).

The .mrimg files are immutable, and mounting them does not
allow them to be changed.

Older versions of Macrium have a mrimg to VHD converter,
and the VHD is a container for virtual machine usage. A
VHD file can also be navigated with 7ZIP. I think I tried
taking a Macrium 7 MRIMG and using Macrium 6 VHD converter,
and it still worked, but there's no guarantee that
such a conversion is valid. They've stopped supporting the
converter in Macrium 7, which is why I was using Macrium 6
to attempt the conversion.

There are a fair number of options on Macrium, which
do not involve doing an actual restoration. If you need
to pull a single file out of an MRIMG, it's easy to do.
You don't have to restore 200GB of stuff to get your
TODO.txt file out of there. It takes about two minutes
work to get the TODO.txt list.

Paul

VanguardLH wrote:

Terry Pinnell wrote:

If I change my simple 'weekly Fulls' to a G-F-S method, your
configuration details will prove very helpful. Especially as you have
actually *restored* on several occasions, which I hope I can continue
to avoid!

But if you never restore, you don't know if the backup chain is okay.
The backup will, if the option is enabled, do a hash on the backed up
files against a hash of the current files on the drive(s), but that's is
not the same as actually reading the files out of the .mrimg backup
files to make sure they work. Some folks will restore to a spare
partition to check they can read from the backup files to do a restore.

I probably do a restore about once a month usually because it is far
easier to restore all registry or file states to eradicate software than
to run the installer (which are never clean) and having to hunt for
remnant registry entries and files to delete (and some registry entries
are so buried in deep levels with restrictive permissions which won't
recurse to subkeys that it can take a long time to delete a registry
key). regedit.exe doesn't show all of the registry, either.

Some MS updates have royally ****ed over a lot of users. I haven't been
hit, so far, but that doesn't discount the tribulations that other users
have incurred due to MS updates. Since Microsoft is pushing them out
during the month and every 6 months for the major updates, I still want
to save a manually instigated backup image before applying any updates
to Windows. For apps, I don't bother saving a backup before updating
them, because they are easy 'nuff to eradicate, reinstall fresh, and
have far fewer updates to get up to date on the apps.

Thanks.

I take your opening point about restoring, but I'm not brave enough to wipe my OS as
an experiment!

I have plenty of disk capacity, either on my internal 4 TB D or one of my external
USB drives. So as a second-best experiment is it possible to restore my OS disk (C)
C: image (135 GB) to a folder on D, say D:\Macrium-Restored? Obviously the all
important bootability test would be lost, but it would give me some confidence in
the procedure.

Terry, East Grinstead, UK

Terry Pinnell wrote:
VanguardLH wrote:

Terry Pinnell wrote:

If I change my simple 'weekly Fulls' to a G-F-S method, your
configuration details will prove very helpful. Especially as you have
actually *restored* on several occasions, which I hope I can continue
to avoid!
But if you never restore, you don't know if the backup chain is okay.
The backup will, if the option is enabled, do a hash on the backed up
files against a hash of the current files on the drive(s), but that's is
not the same as actually reading the files out of the .mrimg backup
files to make sure they work. Some folks will restore to a spare
partition to check they can read from the backup files to do a restore.

I probably do a restore about once a month usually because it is far
easier to restore all registry or file states to eradicate software than
to run the installer (which are never clean) and having to hunt for
remnant registry entries and files to delete (and some registry entries
are so buried in deep levels with restrictive permissions which won't
recurse to subkeys that it can take a long time to delete a registry
key). regedit.exe doesn't show all of the registry, either.

Some MS updates have royally ****ed over a lot of users. I haven't been
hit, so far, but that doesn't discount the tribulations that other users
have incurred due to MS updates. Since Microsoft is pushing them out
during the month and every 6 months for the major updates, I still want
to save a manually instigated backup image before applying any updates
to Windows. For apps, I don't bother saving a backup before updating
them, because they are easy 'nuff to eradicate, reinstall fresh, and
have far fewer updates to get up to date on the apps.

Thanks.

I take your opening point about restoring, but I'm not brave enough to wipe my OS as
an experiment!

I have plenty of disk capacity, either on my internal 4 TB D or one of my external
USB drives. So as a second-best experiment is it possible to restore my OS disk (C)
C: image (135 GB) to a folder on D, say D:\Macrium-Restored? Obviously the all
important bootability test would be lost, but it would give me some confidence in
the procedure.

Terry, East Grinstead, UK

Right-click a .mrimg file and look for an item
that was put there by Macrium. That allows you to
examine files by mounting the partitions that
are inside the .mrimg, and without a conflict with
the same partition already locally in use of the machine.

I can back up C: to a .mrimg, then right-click the big file
and select "Explore" or whatever, and cause the backed up
partition to appear as W: and then compare the files if
I want to, or copy files out of W: back onto C: .

You have random access to the .mrimg contents.

You can unmount the item later.

Like a lot of mount versus unmount exercises, the
menu items can typically be in more than one place.
Maybe the file explorer items on the left, you right-click
an item there and a second thing exists to unmount
the W: you set up.

Mounting the .mrimg does not give you the ability to
write it. If you don't click read-only, that doesn't
mean you can trash the .mrimg, it just means the
changes will be thrown away when it is dismounted.
I don't know where any deltas would be stored, and
really, in most situations, it's not necessary for
it to be writeable. Sometimes Windows needs to write
some tiny thing while you're working, and that's
probably why that option exists when setting up W: .

And you should occasionally run "Verify" on the .mrimg
files, just in case. I just found another .mrimg
a few minutes ago, which seems to be ruined, and
I can't find ".mrimg" string inside the file. Usually
the name of the recorded file, is stored inside itself,
and that's as close to a Macrium identifier as I can find.

Paul

Paul wrote:

Terry Pinnell wrote:
VanguardLH wrote:

Terry Pinnell wrote:

If I change my simple 'weekly Fulls' to a G-F-S method, your
configuration details will prove very helpful. Especially as you have
actually *restored* on several occasions, which I hope I can continue
to avoid!
But if you never restore, you don't know if the backup chain is okay.
The backup will, if the option is enabled, do a hash on the backed up
files against a hash of the current files on the drive(s), but that's is
not the same as actually reading the files out of the .mrimg backup
files to make sure they work. Some folks will restore to a spare
partition to check they can read from the backup files to do a restore.

I probably do a restore about once a month usually because it is far
easier to restore all registry or file states to eradicate software than
to run the installer (which are never clean) and having to hunt for
remnant registry entries and files to delete (and some registry entries
are so buried in deep levels with restrictive permissions which won't
recurse to subkeys that it can take a long time to delete a registry
key). regedit.exe doesn't show all of the registry, either.

Some MS updates have royally ****ed over a lot of users. I haven't been
hit, so far, but that doesn't discount the tribulations that other users
have incurred due to MS updates. Since Microsoft is pushing them out
during the month and every 6 months for the major updates, I still want
to save a manually instigated backup image before applying any updates
to Windows. For apps, I don't bother saving a backup before updating
them, because they are easy 'nuff to eradicate, reinstall fresh, and
have far fewer updates to get up to date on the apps.

Thanks.

I take your opening point about restoring, but I'm not brave enough to wipe my OS as
an experiment!

I have plenty of disk capacity, either on my internal 4 TB D or one of my external
USB drives. So as a second-best experiment is it possible to restore my OS disk (C)
C: image (135 GB) to a folder on D, say D:\Macrium-Restored? Obviously the all
important bootability test would be lost, but it would give me some confidence in
the procedure.

Terry, East Grinstead, UK

Right-click a .mrimg file and look for an item
that was put there by Macrium. That allows you to
examine files by mounting the partitions that
are inside the .mrimg, and without a conflict with
the same partition already locally in use of the machine.

I can back up C: to a .mrimg, then right-click the big file
and select "Explore" or whatever, and cause the backed up
partition to appear as W: and then compare the files if
I want to, or copy files out of W: back onto C: .

You have random access to the .mrimg contents.

You can unmount the item later.

Like a lot of mount versus unmount exercises, the
menu items can typically be in more than one place.
Maybe the file explorer items on the left, you right-click
an item there and a second thing exists to unmount
the W: you set up.

Mounting the .mrimg does not give you the ability to
write it. If you don't click read-only, that doesn't
mean you can trash the .mrimg, it just means the
changes will be thrown away when it is dismounted.
I don't know where any deltas would be stored, and
really, in most situations, it's not necessary for
it to be writeable. Sometimes Windows needs to write
some tiny thing while you're working, and that's
probably why that option exists when setting up W: .

And you should occasionally run "Verify" on the .mrimg
files, just in case. I just found another .mrimg
a few minutes ago, which seems to be ruined, and
I can't find ".mrimg" string inside the file. Usually
the name of the recorded file, is stored inside itself,
and that's as close to a Macrium identifier as I can find.

Paul

Thanks, I'll try those suggestions.

Terry, East Grinstead, UK