Kaseya Community

Kaseya 2008 BUDR Issues/Features

  • We are scheduled to upgrade to K2008 next week. I have been keeping a close eye on the different challenges so far with the upgrade and things are looking good. This morning I started to see a few posts on different threads about BUDR changes. Like how the backup folder was changed from the machine name to the new MachineID (a number). With this thread I am hoping to consolidate the discussion about these issues and changes.

    Problem I hear people talking about:

    Backups used to backup to destinations looking like this

    \\nas\budr\\volbackup\

    It is now looking something like this:

    \\nas\budr\30942364\volbackup\


    This is a really big change. Does anyone know if the folder is actually being renamed from the old to new or is it creating a whole new folder? Also, I have heard that after the upgrade it kicked off FULL backups on every BUDR out there upon the next backup. Can anyone confirm this?

    I want to try to prevent running out of backup disk space at clients.

    Thank You

    Legacy Forum Name: Kaseya 2008 BUDR Issues/Features,
    Legacy Posted By Username: far182
  • far182

    Problem I hear people talking about:

    Backups used to backup to destinations looking like this

    \\nas\budr\\volbackup\

    It is now looking something like this:

    \\nas\budr\30942364\volbackup\


    This is a really big change. Does anyone know if the folder is actually being renamed from the old to new or is it creating a whole new folder? Also, I have heard that after the upgrade it kicked off FULL backups on every BUDR out there upon the next backup. Can anyone confirm this?


    Here is what we experienced:

    • Roughly half of our servers RENAMED their existing folders to , and proceeded with an incremental backup.
    • The other half created a NEW folder (leaving the folder alone), threw the error "No previous backups found", and proceeded with a full backup.


    Obviously the intention was to make them rename their folders... But that didn't happen in all cases, and we've now got tons of new backups out there that we really weren't planning for.

    What seems to work to prevent that though... If you manually rename the folder to , the backup software will look for that folder automatically and will perform an incremental.

    AR

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: arobar
  • I also had problems with folders not being renamed correctly. Some worked, some didn't.

    In addition to the folders, the .tib files are also renamed, but this didn't happen on the corresponding offsite replication server, and this hosed by offsite replication until I forced a new agent update on the offsite server and manually renamed the folders/files to match the local copies. Big pain!

    I had failing folder backups, which then mysteriously began working after a couple of manual tries, only to fail again at the next scheduled interval. Then work manually. I'm hoping this was hotfixed and tonights backups will go more smoothly.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: Alan M
  • I have also noticed that the Backup Status screens (the new one) seems to loose contact with some backup jobs and make them as finished or failed when they are still run.
    It is also still the same Acronis verison as well which is disappointing.

    Mike

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: mfelder
  • OFFSITE REPLICATION:

    In Kaseya 2008 BU-DR, changes and enhancements were added for the management of backup archives. To facilitate the change, the folders for the backups on the local image location were renamed. This did not occur on the offsite server.

    We are fixing this ASAP and will update you as soon as it is available. To avoid a full sync of the local backups with the offsite server, please turn-off the offsite replication.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: kaseya
  • arobar
    Here is what we experienced:

    • Roughly half of our servers RENAMED their existing folders to , and proceeded with an incremental backup.
    • The other half created a NEW folder (leaving the folder alone), threw the error "No previous backups found", and proceeded with a full backup.


    Obviously the intention was to make them rename their folders... But that didn't happen in all cases, and we've now got tons of new backups out there that we really weren't planning for.

    What seems to work to prevent that though... If you manually rename the folder to , the backup software will look for that folder automatically and will perform an incremental.

    AR

    What's really got me stumped is where those new numbers are coming from and how to find out which folder equates to which machine now.

    We seem to have a had a bunch of machines kick off Full backups which filled up the backup drive and now I can't find out which folder is which so that I can delete some old backups from machines that are not so critical.

    Anyone know where these stupid numbers are coming from and how to cross reference them?

    (What the heck was wrong with the old way?)


    Michael

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: mjezard
  • Just got a ( really fast) response from tech support.

    It turns out that those "magic numbers" for the backup folders are the GUID of the machine.

    I still hate it ( the old way was much more intuitive) but at least I can find the machine now.


    Michael

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: mjezard
  • mjezard
    (What the heck was wrong with the old way?)


    The old way was named-based, which presents a real problem if you rename an agent. Previously if you re-named an agent you hit the exact same problem, but there was no fix (folders renamed, TIB files weren't recognized, etc). The new UID-based folders for everything are really the correct way to do things so that you can rename agents at will... But since the scripts to rename the name-based folders didn't work, it caused us several headaches.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: arobar
  • Just a thought, but can they put in the "DO NOT DELETE" text file, a list of all GUID and Associated Agent Names? Thus if we are searching manually through the backup device we can check this file to find what machine the data came from?

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: Nathan Coulthard
  • Nathan Coulthard
    Just a thought, but can they put in the "DO NOT DELETE" text file, a list of all GUID and Associated Agent Names? Thus if we are searching manually through the backup device we can check this file to find what machine the data came from?


    I really like this idea! This would simplify things greatly for scenarios when you need to restore from a NAS with 50 devices backing up to it (or just any type of manual check of the backups).

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: arobar
  • mjezard
    What's really got me stumped is where those new numbers are coming from and how to find out which folder equates to which machine now.

    We seem to have a had a bunch of machines kick off Full backups which filled up the backup drive and now I can't find out which folder is which so that I can delete some old backups from machines that are not so critical.

    Anyone know where these stupid numbers are coming from and how to cross reference them?

    (What the heck was wrong with the old way?)


    Michael


    You can locate the machine ID under the machine info tab on the machine summary screen. This will allow you to locate the backup folder for the machine.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: Chris T
  • I really wish I had read the forums before I upgraded. Shame on me. This is a disaster! I have 150 different backups running, with a few offsite replications that are CHOKING on this change. It's gonna be a long night.

    D

    Eek

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: DeWayne Ashcraft
  • I REALLY like the idea of putting the GUID/Computer name in the txt file. Usually, I am remoted in, trying to figure out which folders I can prune on the offsite server or on the NAS that is holding several computer's files. Yes, I can look the GUID up in the console, but it is a pain.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: rcspang
  • Our BUDR folder names also changed sporadically. Some changed, some were created new. All are unreadable by humans without thinking like a detective. Some clients ran out of disk space on their backup targets as a result.

    I understand now why the folder names were changed to the GUID of the machine – it’s far more scalable and survives name changes better. But it still adds a dependency to the recovery scenario. You now need to be able to access the KServer in order to determine what the backup location is for any one machine. The previous way was far more friendly to humans.

    Why not set the folder names to “.Machine.Group”? Or better yet, Group.Machine.GUID”. This would make it far easier for a person to drill down to the machine in question, especially when client files are mixed, such as at an offsite facility. (of course, mixing of client files wouldn't be necessary if we could define multiple targets on our offsite server!). Surely Kaseya could code a routine to parse the folder names and scrape the GUID to manage the folders.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: jim@blacktuskgroup.com
  • Hey Jim,
    Just a quick thought on this... you could make sure the image location contains the name if the machine in it. This way you'll know what the backup is for and still get the best of both worlds. Just a thought.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: boudj