Discussion in 'backup, imaging & disk mgmt' started by TheKid7, Aug 19, 2011.
Thanks Brian. Should we start new backup chaings
Yes for incrementals. No for differentials.
Whoopee. Now the third incremental and on are taking about 1:30 running in windows, compared to 16 minutes.
I like the clean and neat way of doing incrementals/differentials by IFW.
Brian, I have not yet get a chance to do these tasks, but when Win10 Creators Update released, I'll probably fresh install the new OS and give IFW/IFL a go using differentials.
So is not risky to say this Metadata technology is better (if not best) over Macrium's, Acronis' and others similar technologies?
Well... start using the new IFW MetaData technology and measure it against the speed of Macrium and Acronis when doing differentials/incrementals... see what the results really are. IFW was one of the few imaging applications left not using metadata for incremental/differential imaging previously... this change should be a huge deal for its users.
Thanks. I won't do that, I haven't used those programs before so I'm not skilled enough, hence I was just asking for some opinions.
Perhaps they waited to mature this technology quite enough to incorporate into their products to be the best ones.
Using metadata is not an immature technology for doing Incrementals and Differentials... it's been around for a long time, many years in use by other vendors. I never really understood why Terabyte Unlimited hadn't moved their imaging product in that direction earlier then they have.
Saying that... they have made a coupla big moves in v3 that has made this product much more competitive in the imaging product space. The first being the use of a much more multi-threaded application... allowing it to use many of the multiple cores (and threads) available in today's CPUs. This has allowed for a sizable speed increase in its ability to compress data and create faster images.
The second being the recently released metadata imaging technology (v3.06). As I mentioned above, this is very new for Terabyte but not for a lot of the rest of the imaging industry. This will enhance their Differential & Incremental imaging speed immensely.
The only thing really missing from this product now (as well as many others) is the ability to use that very same metadata concept in their image RESTORE technology. This is what sets aside Macrium Reflect and AX64's FlashBack (gone but never forgotten) from the rest of the imaging products available today. Restoring just the differences between the current resident partition and the image being restored, rather than the entire image chain of that partition, is what makes "restores" so much faster with metadata technology. I personally believe that this technology will be next on Terabyte's major feature development road map... it's a logical progression in their imaging technology. Macrium has already proved that it works very well and is very reliable... their just waiting for the next real competitor in their imaging space.
Perhaps I used a bad wording. What I meant to say is TeraByte waited to mature well enough their own Metadata Imaging Technology (I guess this tech is same in general terms different in its inner code for each vendor) to release their products incorporating it.
Agreed. And I'm so glad to read this too.
Well... that may, indeed, be the case but I feel they waited waaaay too long to incorporate the technology. IFW's weak point was always the time it took to do, not FULL images (they were always pretty quick), but Differentials and Incrementals. Now I know a lot of their users didn't mind that very much... to each his own, I guess. But, personally, I always wanted quick Incrementals... mainly because I used to do a lot of Incrementals and restores during a given day. I was an IFW user for many years as far as FULL imaging was concerned, but made my way away from it due to the above shortcomings and as soon as metadata restoration techniques were developed by Macrium, I jumped on their Reflect product. I needed an imaging program with a restoration speed that approached that of Rollback RX (something else I used to use) due to my many daily restorations... Macrium Reflect hit the spot.
But seeing IFW moving more in to the mainstream as an imaging product... it gives me cause to stop and reflect a bit. I've always liked their product... so much so that I helped discover/develop a way for IFW FULL images to capture Rollback RX snapshots while running under a LIVE Windows System (thanks to PhyLock), something I needed very much at the time.
I modestly have been contributed to translate the gui to Spanish lang.
Any contribution like that is very important... not only for you as a possible Spanish user, but for Terabyte in broadening their markets for their product.
@TRBF: i bow to your expertise and I get what you are saying bout keeping utd and using best practices.
From my perspective Terabyte is always ahead of the curve because of the phenomenal reliability and support through all the ins and outs of Windows and MS creating any stuff up they can.
I am a bit dull, Since finding Terabyte in 2004, I have not really looked at other options, just does all I need and more for imaging & boot mgt., never really failed me. Best software purchase -ever-. (FDISR second best)
MAcrium does look good: I dont do that many restores, time not so critical here, but still looks a good option.
I am always happy to follow Terabytes lead.
My experience is that Terabyte never does anything before robust testing = peace of mind for me
PS: nice tools
Speaking of IFW ... Bryan, et al...
What are the "special" options needed to completely image a BOOTable UFD properly, and restore it to a BLANK UFD with the same capability? I tried the DEFAULT and the restored device would not BOOT (needing an MBR "helper"... msg from the GRUB Loader MBR).
Any help, greatly appreciated...
Create an Entire Drive image (not a partition image).
Restore the image to any UFD brand you like. Full of files or empty. It doesn't matter (the files and folders will be deleted). Do an Entire Drive restore (not a partition restore). No special options need to be selected. If you are restoring to a smaller UFD you will get a message, "The selected destination is not large enough". Then (not before) select Scale to Fit. It should take less than a minute.
Nope... it worked just fine. Not sure why the first problem... it may have been caused by my "accidental" SETTINGS change from "BiOS AUTO" alignment to 1mb (I lied about being DEFAULT settings ). I don't remember doing anything else. Even though the 1st partition on the SOURCE UFD was 1mB aligned anyway
Anyway... it's repeatable and works just fine, thank you very much!
I was trying out a whole bunch of UFD disk image makers (almost all were intolerable slow) and totally forgot about my IFW app (Macrium Reflect cannot image UFDs <duh!>).
EDIT: Read on...
These processes sometimes work, sometimes they don´t, apparently depends on the UFD. A few days ago I tried twice to copy a multi-boot UFD con IFW. In both cases the processes finished successfully, in both cases the boot failed.
Robin, I'm seeing the same thing... with no rhyme or reason for the issue. The one mentioned above was an HP (PNY re-labeled) 64gB UFD. The first attempt to restore that drive from Bryan's suggested method produced an unBOOTable UFD with the msg "Need MBR helper" (comes from the GRUB Loader MBR). The 2nd attempt produced a working BOOT device.
I just tried a different 64gB UFD (Lexar) with the same image and it produced a "Need MBR helper" situation. Repeated the restoration resulting in the same "Need MBR helper" result.
The image is an Easy2BOOT multiBOOT creation (grub loader) that was originally created in the above HP UFD. The first attempt, after imaging the Easy2BOOT image, was to an identical HP device producing the "Need MBR helper" unBOOTable msg. 2nd attempt to same HP device (identical twin) did work.
There's something very strange with imaging UFD multi-BOOT images... I just don't have a handle on it yet. I would say maybe an alignment issue but IFW is not supposed to be changing that in the imaging/restoration process.
OK, some discoveries along my sojourn... and this is using v3.06a (don't know about the rest)
When imaging a multi-BOOT UFD (and probably any other type of UFD)
When a FULL backup is done to the entire device, it looks as though everything is in the image to restore most anything... MBR + 1st track (EMBR), partitions, etc.
When you restore that complete image to a specific device (in my case, another BLANK UFD), what's returned was the MBR (LBA-0) and all the partitions included in the image. What WAS NOT RETURNED was the balance of the 1st track (LBA-1 to LBA-<n>). As a result, since the BOOT loader in use for this device was a GRUB Loader (an extended MBR of an additional 15 disk blocks), it would not BOOT due to the lack of the rest of the loader being present. This only happens when you're restoring a whole device image to a whole BLANK device. In this mode, not even a "Restore first track" option is offered in the "Restore options" page... most likely because it shouldn't really ask, it needs to do it anyway due to the restore type. The problem... it doesn't. I think it's either a bug in IFW or my understanding of any options available.
If you restore only a partition, the "Restore first track" option does become available in the "Restore options" page and if I select the entire GRUB Loader space from that track (20-blocks), it does get loaded with the partition restoration and the device BOOTs fine.
So, at the moment, with this "anomaly" in place, I need to restore an entire device image to another device, then follow that with a single partition restoration including how ever much of the EMBR I need for the loader to operate correctly. If I do those two operations during a restoration of a multi-BOOT device image, I may be sure that it will operate correctly.
I'm sure the above operations should not be required for this type of restoration. A simple solution would be for me to figure out what I actually did wrong in my SETUP (I really don't think I did anything wrong), or, what I really think needs to be done is for Terabyte Unlimited to either add That same "Restore first track" option to the "Restore options" window on a full device restore... then it could be changed at that point, assuming the user knew how much of the EMBR needed to be restored for a particular BOOTing configuration. Or in thinking about this whole thing a bit more... the DEFAULT whole device restore SHOULD INCLUDE the entire first track (EMBR) that was imaged, after all it is a whole device restore, right?
The above anomaly DOES NOT AFFECT the restoration of any Windows-based BOOT media (WInPE/RE) due to the fact that only the single LBA-0 MBR is ever needed to perform that type of BOOT... the rest of track ZERO is not needed for those BOOT types. All other BOOT Loaders will be affected, though... including BIBM which uses the EMBR space.
Food for thought... if a UFD had ever successfully loaded a multi-BOOT environment, and was fully imaged, it will always work once again in the above scenario. Why, because the EMBR space has already been created, and no partition operations (wiping, zeroing, deleting, etc.) will affect that space, it will always remain. The only thing that will affect that space is some sort of disk wiping software that zaps all the sectors on a disk... it is not part of what partition managers call "unallocated space."
Even if you had a GRUB Loaded multi-BOOT disk previously, then loaded it up with some WinPE variant... you could easily go back to your restored multi-BOOT image due to the fact that only the MBR (LBA-0) in the meantime was changed, not the rest of the first track. In this scenario, IFW would return the MBR to the GRUB Loader state and the rest of the loader would already be there.
Sometimes these things are tough to chase down...
Head is spinning violently ROFL
In my vision of the above... Linda Blair (in "The Exorcist") looks much better than you do
I recall a similar issue a few years ago with IFW and Ubuntu. Grub was occupying over 100 sectors and you needed to select Restore First Track, First Track Sectors 128. (not AUTO)
Does that work?
That works ONLY when using a Partition Restore... the option is not even offered on a device restore, that's the problem. The assumption made by the device restore is... "Sure, I'll restore everything!", but it doesn't. It only restores LBA-0 and the partitions themselves... no additional first track DATA of any kind (the app developer must be a Windows guy ). I think it's a bug... but I don't know how long it's been around.
This particular Grub Loader is only 17-blocks long...
Man... are you up early!
Separate names with a comma.