For recovery speed and space optimization, it would be great if Urbackup could make incremental image backups, and create a full image backup from only the most recent incremental.
This would mean we could quickly restore/mount the full image VHD without taking up a bunch of extra storage space.
Can you describe how you believe that this might work?
-ASB
This might be how synthetic Full Image backups already work, but here is the idea:
An incremental image backup is sent from the client
The Urbackup server combines the incremental image with the last full image backup, and creates a single “rapid restore” VHD.
The Urbackup server deletes the previous “rapid restore” VHD, so that only one full image is kept per client.
The idea is that we can rapidly mount that VHD to a Virtual Machine that is running in a network local to urbackup. This would greatly reduce restore times, as there really isn’t and data being restored. It’s just mounted.
Interesting…
While this does make a form of sense, my main concern is in only having one version to restore to…
Have regularly seen it where it can be days or even weeks before an issue is identified, if you only have last night’s backup to go back to, then you are stuffed…for example, if you do daily backups, what happens if you only find out on Monday…?
What you might want, is a method where you have one backup for the rapid recovery and a separate/secondary that gives you longer retention…
Sorry if the idea is unclear- in no way do I want to only retain one backup. This would just be a “standby” complete image backup for quicker Disaster recovery.
That’s pretty much how image backups and file backups already work, by building on previous backups. Deleting a full image backup also deletes the incremental backups associated with it. (File backups keep copies of individual files so deletes of any kind don’t affect the stored files until all references to an individual file are deleted.) Every backup of any type can always be restored as a full point-in-time backup of the selected drives or files on the client computer at the time of the backup.
It’s also why some of the transfer estimates look really strange - larger than the drive - for incremental images. The CBT option can help the Client determine what needs to be sent.
This is something I would like (for image backups only) for rapid DR…have a “ready to go” VHD I can load in Hyper-V or virtualbox (in addition to all previous incremental backups…basically a reverse delta type backup). I think this could be done relatively easily on the server via the post_incr_imagebackup script and using as per the docs : urbackupsrv -a /full/path/Image_C_XXXXX.vhdz -a /full/path/Image_SYSVOL_XXXXX.vhdz\ -o full_disk.vhd
However the only issue I have is how do I figure out what path name and file name to use for the most recent incremental image? (ie the XXXXX in the above)
How about a “current” symbolic link to the most recent image backup folder(s) the same as for the most recent file backup?
The thing is, though, an incremental could be missing all sorts of files, because it is not a differential backup.
How much more value would such an incremental be over the most recent full backup?
-ASB
BrainWave: Most recent full image could be a week or more old whereas latest incremental would be today (if incremental image done daily). Running the “combine image” command above will include latest full and all incrementals if you specify the latest incremental as the image file name.
Sure, but if the image were a week old, and you picked today’s incremental, it would be missing all the data changed between the full and the incremental.
What “combine image” command?
Are you talking about the following?
https://www.urbackup.org/administration_manual.html#x1-9400010.7