@Antarctica - I'm not sure about JP's 2nd suggestion. Since I don't know how Macrium fingerprint's their license information, an image transfer of that license to a different System (with a different hardware fingerprint) may have issues involved. JP's 1st suggestion would be best and should provide for no issues as far as your license is concerned.
Thanks TheRollbackFrog for your input. I won’t be migrating image so I will use JP’s first suggestion.
I am running Windows 10 Pro 64-bit (1803) latest with all updates. I am just doing my regular routine backups at the moment, first with Bvckup 2, then now with Macrium Free (latest). With my new backup drive, Macrium is showing it as "Unformatted Primary" and therefore I am concerned that Macrium does not see the file system and therefore not going to proceed with image backup just yet because I am worried that it may destroy my other backups on that drive (made successfully with Bvckup 2). So I will wait for an answer from the experienced imaging and backup folks here first before moving forward. Brief question: Does Macrium Free (latest) not support ReFS file system at all? Or just visually not showing the ReFS file system? If not, this would be a huge deal breaker for me with Macrium since all of my backup drives are ReFS file system. Thank you for your time.
As of May 17, 2017, it did not support the ReFS FileSYstem as of yet... and I haven't heard anything to the contrary since then. Edit: File & Folder, yes... imaging, no.
@WildByDesign - posted today at Macrium was a confirmation of the fact that ReFS is NOT CURRENTLY supported but will be supported in a future update (no time frame offered). It will have similar support to NTFS but will not include the ability to shrink the file system on restore (limitation with ReFS structure specs).
@TheRollbackFrog Excellent. Thank you for looking into that for me over at their forums. That is certainly good news to look forward to.
I have Macrium Reflect Home Edition 6.3 Pro installed. Should I upgrade to Version 7, are there enough improvements yet to justify the cost of the upgrade? ($35)
John, the only two major features that stand out in difference to your version of v6 is viBOOT (which lets you boot your image into a W10 virtual System <Hyper-V> if you're running W10 Pro just to check it out... you really can't do much else with it) and MIG (Macrium Image Guardian) which does protect your images from possible RansomeWare attack. It also contains a disk tracking feature called CBT (Continuous Block Tracking) which makes Incremental images a li'l bit faster and restores of same a tiny bit faster as well. This feature is only of real use if you do multi Incrementals under the same System session... no gains between reBOOTs. This feature was BETA tested under v6 and was solid as a rock (under v6) when v7 was released. If you're particularly interested in a v6 version of CBT, contact me via PM and I should be able to steer you to the BETA implementation under v6 if interested... it is unsupported as most BETA software is but is fully functional in the latest v6 release from Macrium.
TheRollbackFrog’s response is correct in terms of “banner features”, but if the upgrade is only $35, then some of the smaller improvements I listed in a post a few pages back and am including below may help justify the cost for you: - Better display DPI scaling support for high-DPI displays - Warnings about a job that would restore formerly encrypted partitions onto unencrypted targets - The ability to view the progress of a backup job that started while you weren't logged in - Popup notifications that show the name of the job that's about to run for at-a-glance convenience so the user can decide whether they may want to postpone it - The ability to have scheduled jobs run as the SYSTEM account so you no longer have to store admin credentials with Reflect to run scheduled backups. The latter could cause scheduled backups to break if that account's password was ever changed and the user forgot to update the credentials stored with Reflect. - The ability to store credentials for network targets so the user running the backup doesn't have to have write access. This is necessary if you run backups as the SYSTEM account of course, but even if you want to use your own user account for scheduled backups, this allows you to grant your own account just read-only access to your backup share as a ransomware protection measure during your everyday use, while still granting Reflect write access. Finally, an upcoming v7 release will add WiFi support for Rescue Media and some improvements around the Rescue Media builder interface itself. That’s been in beta for a while now.
Thanks for replies, Frog and jp - I went ahead and upgraded to 7. The upgrade went very smoothly and I am now running 7.1.3317. Appreciate your input.
Hi, How can I achieve the retention plan matching my intention: Define grandpa-papa-son hierarchy where always for the whole backup set my retention rules apply - keep max. 2 full backups, at most one differential image per every single full image, and at most 6 incremental images per every single superior differential or full image, where the only fixed time schedule will be for full backups, and other backup types will follow depending on how the quotas are filled. This would look specifically as following: Week 1 Sat: Full, Sun-Fri: 6x Incremental Week 2 Sat: Differential, Sun-Fri: 6x Incremental Week 3 Sat: Full, .... ... Week 5: Sat: delete the whole chain from week 1 + Full, rest repeats ... It looks that the software requires me to schedule all three types of backups, while I'd prefer make only one schedule for each day and Reflect intelligently decides from how the quotas are being filled which backup to make (this can make the scheme more flexible e.g. when on even saturday the computer is off, it will create differential backup on first following day when the computer is online and the set of incremantals follows)
First, as far as schedules are concerned, have them all occur on the same day and same time... Reflect sorts out which one should be run accordingly. The schedules should be as follows... FULL: <same day/time as the rest>, FREQUENCY=Weekly, EVERY=2-weeks DIFF: <same day/time as the rest>, FREQUENCY=Weekly, EVERY=1-weeks INC: <same day/time as the rest>, FREQUENCY=Daily, Settings=Every Day The RETENTION values should be set up as follows... FULL: Checked. Keep 2 BACKUPs DIFF: unChecked INC: Checked. Keep 6-BACKUPs (if you're only doing 1-Inc per day, if more than 1, then 6-DAYs) Reflect is smart enough to sort out the most prominent backup type when multiple types (Full, Diff & Inc) are all scheduled at the same day/time... it does this very well. Since your Fulls are being run every 2-weeks, no RETENTION control is needed for the Diffs as they will be discarded when the parent Full is discarded. The (6) Incremental backups will be merged forward in time as they are created so that you will always have the most recent 6-Incrementals taken. In the RETENTION area, you should also have the "Run the purge before backup" option unChecked to be sure you lose no previous backups before the present one is completed and successful. This will require space for at least a 3rd FULL in your process, but the space is only needed until the 3rd Full backup is verified, then the 1st one will be deleted. That should do what you ask, I believe...
@Anakunda - I use your same exact scheme, albeit over a 4-week period rather than 2-weeks. I also maintain 7-DAYs worth of incrementals rather than 7-BACKUPs which allows me to take many unscheduled MANUAL Incrementals (snapshots) per day which I use heavily in my System testing environment.
Yes, you will have 3-schedules, but they will create only what you are asking for. With the option set on the FULL and DIFF schedules for "CONDITIONS=Run task as soon as possible after a scheduled start is missed," the chain will continue as you expect above...
Thanks TheRollbackFrog. Now the scheme looks realizable. Second thing I need is to be able exclude certain directories from backup image eg. %temp% and others keeping persistently high loads of temporary files which increase backup image considerably. This was possible by Paragon including in backup script the vd_store_options exclude = "...". No offer for this in Reflect backup wizard, but maybe in the task definition? (undocumented). Including everything into image is dumb, there's alot of stuff that can be safely left out.
There's no "ofishul" method for doing that, especially when it comes to the %temp% area, some parts of the %temp% area may be completely valid for the System session you will be imaging. Best to just clean up your own temp area using the standard Windows "Disk Cleanup" tool. There is an "unofishul" method for doing such but it, basically, is a REGISTRY nightmare and very dangerous for most users to mess with. It's the same method used by Reflect to eliminate HiberFiles, PageFiles, and some System Restore stuff from the current imaging operation.
Another potentially viable method for dealing with temp data would be to use Reflect to generate a script to run the backup (it can generate batch, VBS, and PowerShell scripts) and then manually augment that script to delete the desired temp data before the script line that runs the backup itself. Then associate your schedules with the script rather than the definition file. All of this except the manual script edit can be managed through the Reflect interface.
That's workaround. I'm already doing regular cleanup by Ccleaner. The temporary folders contain still in use files of short presence but of marginal importance for system restore, so I want to keep them at backup time but not wanting them in image. But as I acknowledge it's not available by Macrium (yet).
A question,,,,,,,,,, I noticed that a recent daily snap did not run and when I opened MR I saw that the most recent dif had a conflict and the most recent incr had an error. I ran them both manually and they indicated that the process was successful. I then did a new incr and verified the incr. Verification was successful. Does this mean that all is well?
What I would do is make a new Full, and then go back and restore the other chain. That will tell the story. Pete
Pete, and/or others like Froggie, BrianK, etc. I don't ever use the verify image and haven't for a very long time. Is it actually necessary in order to catch issues like @bgoodman4 ran into? I rarely restore unless a hardware blows a cork and have to replace a HDD or I add a new drive to a new lappy system which is all I use now. Reason being Windows 8-8.1 sports a fabulous feature you have heard of from some user's just like myself, the CustomRefresh restoration. And that's reserved specifically when a fatal file corruption blows a gasket (usually in the registry) and Windows won't boot to the GUI as expected.
As you know, VERIFY is nothing moe than a "feel good" at a particular point in time, usually right after the image. It does let the user know if his System is in good shape (good RAM, good DATA paths, processor doing what it's supposed to, storage device not dropping bits, etc.) at the time of the imaging operation. VERIFY prior to restoration just tells you if the operation has any chance of success... for all the same reasons as mentioned above. Having said that, I use VERIFY for all my automatic imaging operations (end of day FULL/DIFF/INC and mid-day INC) because they are run at low priority and don't bother my System usage when they are running (the end of day shuts down my System automatically... I'm not even on it). All other incrementals (Start of day and MANUAL operations during the day do not automatically VERIFY for me). So far, since February 2015, I have never had a single VERIFY failure... which may cause others to ignore the operation. It's really up to the user. As far as restorations are concerned, and I'm sure both Peter and Brian will concur, we've all done tons of those for a myriad of reasons. Brian does a lot of imaging application testing so to know the application AND the System, you need to know how to do them. Peter does a lot of EVERYTHING testing and as a result, gets himself in trouble which requires restorations to get him out of trouble. I use my imaging System as a Snapshot tool... protecting my System from "unexpected" application testing and (more often than not) Operating System updates (a painful process these days under Windows 10). It's kinda like a very reliable Rollback RX... no risks, just successful results . With Difference Restoration available in tools like Macrium Reflect and Image For Windows (under its new name), Snapshotting can be done reliably and quickly. Although you may not do a lot of restorations (you're just protecting your System after all), you do need to know how to do them successfully, and therefore the process needs to be part & parcel of any learning curve associated with being introduced to an imaging operation. If you wait to do this until you really need it, you maybe be in trouble . Barry's (@bgoodman4 ) issues seem to have stemmed from a process that may have hung (producing no usable image) along the way, followed by another process that could not run due to the first one not having completed. This sounds like a process failure rather than a DATA oriented failure which VERIFY would not have added anything more to his problem picture. Since neither of his automatic processes finished properly, no usable image was most likely produced. Without those, even VERIFY could not have run. When he manually ran those processes (successfully), all should have filled in nicely in his backup chain and all should be good in his ImagingLand. The worst that may have happened is there may be some incomplete image files laying around (depending on how he ended his process chain) and those are completely invalid and are not considered part of his existing image chain... just junk waiting to be deleted. Just remember, "Custom Refresh" may be great for Windows-related issues, but nothing is as good as a bit-for-bit restoration of a broken System (as long as your restored DATA files are of any use to you <ie, not too far out of date>).
