Suppose - Full Backup - Incremental 1 - Incremental 2 - Incremental 3 (Bad) - Incremental 4 - Incremental 5 I can delete Incremental 3, 4 & 5 And the chain will continue normal, right? So what do you mean by "missing links"?
I mean Shadow Defender only on-demand use. Suppose C partition backed to D partition. So - 1. I can disable backup schedule & use Shadow Defender, right? 2. I can shadowed only C partition And backup will be saved on D partition if backup runs when Shadow Defender is running, right?
What do the numbers in this error indicate? Clone failed - Write failed - 22 - 32 I get this error with every clone attempt using the new Windows 10 AU PE image, while clones still succeed using the Windows 8.1 PE image (on the same hardware: from my PC to an external HD via an eSATA interface).
Does hard shutdown affects Macrium or Imaging software? I mean Macrium or Imaging software not doing anything like taking backup, etc... So does hard shutdown affects Macrium or Imaging software?
Some imaging software (Macrium REFLECT Beta CBT, AX64 Time Machine/Time Machine/FlashBack and I believe Storage Protect <SP>) all use a "tracking file" in an attempt to track, in real time, disk surface changes... this tracking file is used primarily for taking their Incremental images. Hard Shutdown/Resets usually affect these tracking files in a negative way, with each of the above mentioned apps taking different steps to recover from the above anomaly. Reflect and SP do a very nice job recovering from the reset anomaly and the AX64 effort has worked "most of the time" when it needs to recover from that event. I don't think any of the above apps contain flaws in their recovery processing of that tracking information, they just recover in different ways.
You mean hard shutdown can damage Macrium or Imaging software created images even if macrium or Imaging software was not doing anything like taking backup, etc... at the time of hard shutdown?
I don't think that's what Peter meant... it cannot damage existing images, it can only affect images being taken at the time, and even those are usually dealt with properly when the next image is taken.
I have FlashBack V2 on one system. The system was hard shutdown & FB was not doing anything at the time of hard shutdown. After system restart, I noticed FB did "Full" backup on the scheduled time.
As I've mentioned before, FlashBack's "tracking file" gets violated during a hard shutdown. After your restart of both your System and FlashBack, the next scheduled or manual FlashBack image sees that the tracking file is invalid and must re-establish that file. To do that, it scans your entire volume, then compares the LIVE System to the re-established tracking file and produces what appears to be a normal Incremental image. The main difference in time being the entire volume re-scan. The result should be a normal Incremental image but taking, what appears as, a full scan's worth of time. That's how that app is supposed to work.
I guess it depends, FB detects & decides & takes image, full or incremental image. On my system, I checked, its full image i.e app the same size as initial full image.
Normal boot, you mean system restart at the time FB taking backup? In that scenario, I get that, 1 program is running, FB is running, restart anyway or cancel. Never tried restart anyway & checking after system restart.
No I just mean a simple restart. The thing for my money you get most reliabily with FB is uncertainity
That is a mistake on FlashBack's part, it's not by design. It should not be taking a FULL SIZE image ever after an interrupted image process or just a normal System reBOOT.
With the AU of W10, all kinds of things seem to be happening to peoples systems... removed apps, failed Windows Task Scheduling, app registrations missing, etc. And if you're running Rollback RX, it better not be installed when the update occurs. Based on that, I guess anything could happen after that update. The way things have been going with W10, I will probably adopt it as my system of choice sometime after 2018
FB did that ever since the first beta for V2 of the software. I abandoned it at that point - no idea if they fixed the issue and it's since reappeared.
Yup, I think they're trying for April (v1704). A lot of users are still dealing with the AU (v1607) anomalies and some v1511 users haven't even been rolled out to v1607 by MicroSloth yet. Katie, bar the door...
I have a Quick question about Reflect starting slowly. I own 64 bit Reflect Home v6.3.1665. All is OK, but have a question about starting it and doing a full image on my wife's new system I built her a z170 system with an i7-6700k and 32 GB memory. I also installed 64 bit Windows 10 Pro. The "issue" seems to be this. After her configuring this new system for most of the day, she will ask me to run her backup for a new full image. No problem, as I do the Backup of her Samsung 512 GB 850 Pro SSD. On her system, and on mine, when I double click REFLECT it comes up in a second or 2. However, on hers, after she has been moving files and configuring her new system all day, when I double click REFLECT, the system seems to be doing nothing for about 15 or more seconds with the drive light on. It looks like it is checking something on the SSD. When it does come up, I can run the backup as normal and it is very fast. After the image is done, I can close Reflect. If I try to bring it up again, it comes up in the normal 1 second or so. So, what could the reason be that it sometimes takes so long to come up after my wife has been configuring her system all day?
If you're sending your images to a USB connected HDD, there's a good chance it's powering down between uses. Reflect won't see it 'til it gets back up and is running on the System. I have this happen all the time with a USB3 connected disk that is my tertiary backup device. The 1st Reflect attempt is very slow, all others in a reasonable period of time are normal ('cause the device is not asleep). If you don't access it in a while, it will go back to sleep.
