Rollback imaging (again)

Discussion in 'backup, imaging & disk mgmt' started by nexstar, Sep 6, 2007.

Thread Status:
Not open for further replies.
  1. nexstar

    nexstar Registered Member

    Joined:
    Jun 23, 2004
    Posts:
    371
    Location:
    Southampton, UK
    There's obviously some need for a little clarification on Rollback imaging so I thought I'd note down some of my observations. My main experience is with Drive Snapshot and so this is all based on that but I am sure this would also apply to other imaging software.

    One criticism often levelled at DS is that the restore options are either using DOS commands or by making a BartPE/UBCD CD and running DS within that environment. I recently made another UBCD and, once downloaded, it probably took less than 15 minutes and about half a dozen mouse clicks to produce an iso ready for burning. It is very simple and seems to have been a lot easier than my attempts to download the ShadowProtect recovery iso at the moment :( .

    In the following, a 'normal' image is just as you would generate any image, A 'raw' image describes the 'Maintenance Mode' advanced option in Drive Snapshot which will save every sector on the partition, even if it is, allegedly, unused.

    I thought that some examples of time and storage requirements might be helpful. These are all based on a 15GB partition with 5GB of data on it. Three snapshots are included but it is a fairly clean install.

    There are four main options for imaging which will produce very different results.


    Option 1)
    Action:
    Normal image made within Windows.

    Result:
    The current state of the system will be saved.
    No other snapshots will be preserved.
    Rollback will need to be re-installed on restoration.

    Speed to save/restore: 6m 47s/6m 02s
    Size of image: 2.4GB

    Comments:
    This is the fastest and gets you the current state back. As we are talking about a disaster recovery scenario, then I see no real problem with this option. You can make images of your other snapshots as you go should this be useful but an image of your current system is probably what most people would be quite happy with in case of disaster and is also probably one more image than a lot of users have :) .



    Option 2)
    Action:
    Raw image made within Windows.

    Result:
    The current state of the system will be saved.
    No other snapshots will be preserved.
    Rollback will still be installed.
    (MBR might need to be restored if it has been damaged/replaced)

    Speed to save/restore: 17m 47s/15m 10s
    Size of image: 2.6GB

    Comments:
    A trade-off against speed and storage space but does save you the hassle of having to re-activate Rollback.



    Option 3)
    Action:
    Normal image in UBCD environment.

    Result:
    The baseline image will be restored.
    No other snapshots will be preserved.
    Rollback will need to be re-installed on restoration.

    Speed to save/restore: 5m 04s/6m 08s
    Size of image: 2.4GB

    Comments:
    Probably the least useful option.



    Option 4)
    Action:
    Raw image made in UBCD environment.

    Result:
    The current state of the system will be saved.
    All snapshots will be preserved.
    Rollback will still be installed
    (MBR might need to be restored if it has been damaged/replaced)

    Speed to save/restore: 14m 26s/16m 12s
    Size of image: 2.6GB

    Comments:
    Another trade-off but if you are a confirmed geek or really do have a favourite set of snapshots then this the one to use :) . Differential images can also be made but they take as long as a full image would. However, they take up a lot less disk space.


    Graham
     
  2. appster

    appster Registered Member

    Joined:
    Jun 19, 2007
    Posts:
    561
    Location:
    Paradise
    Interesting comparison Graham, and I'll bet that Restoring with UBCD was a lot simpler to perform than when using DS' (DOS) recovery floppy! ;)
     
    Last edited: Sep 6, 2007
  3. Longboard

    Longboard Registered Member

    Joined:
    Oct 2, 2004
    Posts:
    3,238
    Location:
    Sydney, Australia
    Nice little tour.

    There's no question that DS is a great app.
    The -ahem- difficulties for endusers in that there is no glossy front end just heightens the charm for me.

    heh: I'm the only person at my local HW shop that still asks for floppy drive.
     
  4. ErikAlbert

    ErikAlbert Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    9,455
    Thanks for the info.
    So there is only one option that keeps your snapshots intact, the one with a RAW image and that's what I thought also.
    That's one of the reasons, why I don't use RBRx. I like to keep my snapshots and ShadowProtect restores all my snapshots without RAW image, which seems to take alot of time.
    I assume that a RAW image also includes backup of FREE SPACE.
    How much time will it take to image a 500-750gb-harddisk in RAW mode ? :rolleyes:
     
  5. Huupi

    Huupi Registered Member

    Joined:
    Sep 2, 2006
    Posts:
    2,024
    I guess it take lots of time to image free air.
     
  6. nexstar

    nexstar Registered Member

    Joined:
    Jun 23, 2004
    Posts:
    371
    Location:
    Southampton, UK
    Not necessarily.

    For me, the question is academic as I don't mix my system and personal data. So the largest partition that I'd be likely to image in raw mode is 30GB. However, as I had a new 200GB drive sitting on my desk this morning, I left it backing up in raw mode :) . It took 64 minutes to backup and the image size was 89MB.

    I realise that I must be one of the few people on the planet that doesn't like FD-ISR but I do own a copy and stopped using it a couple of years ago as I felt that it took up too much space and that I could achieve something similar using differential snapshots with Drive Snapshot in much less space.

    My thinking goes like this:

    Suppose I have a 30GB system partition with 15GB used. I then take 5 snapshots, each of them increasing in size by 1GB each time.

    The disk space requirements for three possible methods (ignoring potential file compression) would be:

    Rollback:
    15GB+1+1+1+1+1 = 20GB

    Drive Snapshot:
    15GB+15+1+2+3+4+5 = 45GB

    FD-ISR:
    15GB+15+16+17+18+19+20 = 120GB

    The maximum time that the entire 30GB partition is going to take backing up in raw mode, even on my ancient laptop, is 30 minutes. FD-ISR is going to take 2 hours and is going to require me to have a large hard drive just for the system, even before I start thinking of any personal data.

    I certainly wouldn't suggest that anyone changes their strategy based on any of this but I just want to point out that it is not as ridiculous a method as might be first assumed.

    Graham
     
  7. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    This analysis assumes only one mode of using FDISR, one that I for one would never use, as it doesn't make sense. You are using a mode of operation that is based on Rollback. In Rollback in you have snapshot A and B and want to add 1 gig, you can't go back and add 1 gig to A, so you take a new snapshot. In First Defense if I wanted to add new stuff and each addition was 1 gb, I add it to my main one and then do a copy/update. So my total space would never be higher than 15+21 or 37gb. Should I want to do what you described for some reason, I'd use archives instead of snapshots. Rollback still doesn't handle that very elegantly. So this comparison is really meaningless.

    Bottom line is imaging in Rollback still isn't clean or this thread wouldn't exist.

    Pete

    PS. I am not knocking Rollback. I own two licenses to version 8. I just wished it ran reliably on my machines, as it does have some very valuable advantages.
     
    Last edited: Sep 7, 2007
  8. nexstar

    nexstar Registered Member

    Joined:
    Jun 23, 2004
    Posts:
    371
    Location:
    Southampton, UK
    Damned if you do and damned if you don't :) . In an effort to improve the accuracy of the information in some threads with regard to RB imaging, I felt that a quick summary might not go amiss. If, in doing so, I have managed to perpetuate the idea that there is some sort of problem in imaging RB then I've obviously just shot myself in the foot!

    Sorry, see how the misinformed can get it totally wrong. At least I didn't go for the 60,000 snapshot example ;) . To be honest, the example didn't even need to mention FD as it was really just to show that even raw RB images can be relatively compact.

    Sorry (again!), I don't want to examine this to the n'th degree as that was not the point of the exercise but, why can't I go back and add 1GB to A? I've probably misunderstood what you meant.

    Well, 'meaningless' seems a bit harsh :doubt: , but at least I ended up with five snapshots whereas you only got two ;)

    I think that the bottom line is that RB users and FD-ISR users should be allowed to get on with using their preferred solution in whatever way they choose :) .

    As far as reliability goes. I can honestly say that I have probably restored 100's of images. Not one of those has been as a result of Rollback failing. BUT, because I am fully aware that RB is reliant on protecting the existing data (on a drive that can fail at any time) rather than making a copy of it somewhere like FD-ISR, then I would always make sure that I had a recent image to fall back on. (phew, managed to get it back on topic before a mod noticed :) ).

    Graham
     
  9. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    ROFL. I didn't mean to give you a hard time. and yes you are right, you can certainly go back and add data to any Rollback snapshot. My duh.

    Comes down to what you said. You have to understand the software you are using and make sure it fits what you need.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.