Restore Failure

Hi,

I am currently testing BuddyBackup and have discovered a very strange anomally, which results in a total restore failure:

Install BB on machine 1, and then setup a backup to 2 network drives on 2 separate machines, using the USB 'Full Sync Mode' backup option.

The backup runs and all is fine.

If you then delete one of the network backup locations (from the machine in question - not through the BB machine doing the backup/restore) and then try to perform a restore, BB says that it is waiting for a backup location to come online - and 'lowlights' the locations icon in the BB control panel.

This state did not change. (At least for a matter of hours).

The backup locations were simply folders on other PC's and throughout the experiment were viewable through windows explorer and 'connected'. I checked ping/permissions/explorer/RDP etc all worked fine.

If you then cancel the restore, remove the lowlighted backup location from the BB control panel and run the restore again, everything works fine and you get your files back.

The reason I deleted one of the backup repositories, was to test the product under this scenario - as it is my experience with novice users, that this is exactly what one of them might do. If this then renders the backup un-restoreable, you have a fairly big problem.

I would, therefore, be most grateful if someone can show me the error of my ways or explain that this operation is by design or a bug.

Many Thanks,

Tim

Hi John,

I used RDP to connect to the machine (I was using as a backup destination) and then deleted everything inside that folder.

It may seem like an extreme test, but I am searching for a solution to offer my customers, so have embarked upon a simply huge backup software review & test program. The program tests commercial and free software side by side, and am disappointed to say I have found nothing fo far, that fulfills my requirements 100%.

That said, I really like BuddyBackup - it's currently in joint 1st place and would be an outright winner, if it was more robust: i.e. it does not seem to know if a restore is possible - it tells you the backup has been successful without knowing the state of the remote backups. At least, that's what appears to be happening.

I do acknowledge that my testing is extreme, and the things I ask of backup software may never happen in normal use. But, I have 20 years of technical support experience, and the conversation that starts "I'm very sorry, but you have lost the lot..."is unfortunately common.

To this end I'm devoting considerable effort to discover the best possible solutions for home and small business alike.


Many Thanks for your help,

Tim.

Hi John,

Thanks for the update.

Just thought I would add some detail about the restore issue. Basically, what I meant was that when files have been deleted at the backup destination, BB still thinks a restore is possible - and so you try to restore a file and then the restore fails as there is no backup file to restore from.

In other words, BB does not periodically check the validity of the files it backs up at the destination. Hence you get stuck in this circular issue - BB runs backups to the destinations you have selected, but does not replace the files at the location where they have been deleted (or become corrupted and un 'readable'). When it comes to a restore, you can't restore your files, because they don't exist at the destination - even though BB gives no indication that the destination has become corrupt.

Again, I realise this is an extreme example, but it replicates exactly what would happen if hard disk cluster or block errors silently destroyed the data at the backup destination. Or users deleted their buddy's backups by accident - BB wouldn't know that this had happened and wouldn't try to replace the lost backup files - and neither would you, until you tried to do a restore.

This issues would be mitigated somewhat by adding lots of backups destinations (buddies) to your backup. But correct me if I am wrong - even this wouldn't work in every case, because if I understand BB methodology correctly, it does not store the whole backup at a all locations? So it would still be possible that a restore would try and recover files from a corrupted backup location.

That said, I still believe BB is an excellent product - exceptional even - if it performed 'traditional, scheduled local backups' it would clearly be a complete 'winner'. But in the real time, CDP arena, there are products (unfortunately very few), that do periodically check the validity of their remote backups - and replace files or missing backups accordingly. In a nutshell, they periodically test that the backup that is supposed to be at destination A, B etc does actually exist.

Again, I apologise for the rather extreme testing I am doing - I really do believe BB is a superior backup tool. I am just testing everything from Areca to Zamanda (and all in between), to try and find a really bombproof strategy for my customers. I should also reiterate that there are very few CDP products that would check these conditions - most of them would not know if a remote backup had become corrupt.

I sincerely hope this information helps,

many thanks,


Tim.