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
|
|||
|
|||
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 |
Ads |
#17
|
|||
|
|||
Macrium scheduling
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. |
#18
|
|||
|
|||
Macrium scheduling
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 |
#19
|
|||
|
|||
Macrium scheduling
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 |
#20
|
|||
|
|||
Macrium scheduling
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 |
#21
|
|||
|
|||
Macrium scheduling
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 |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|