Kaseya Community

BUDR STILL grey screen's servers!

  • This is purely my opinion, so take it with a grain of salt....

    I have seen many image based backup solutions (including Acronis and BESR) suffer from the GSOD. My opinion is that this is not a bug in the backup products; the problem lies in the way that Windows Server 2003 utilizes virtual memory.

    I make heavy use of both BESR and Acronis. I have some servers that experience this GSOD problem daily, and others that do not experience it at all. I would like to point out that I have not had a single GSOD under Windows 2008 (32 or 64-bit) or Windows 2003 64-bit. I believe the reason for this is that newer operating systems have access to a larger pool of virtual memory (paged, nonpaged, etc). Reference the following MSDN article:

    http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx

    If you look at the chart titled "Memory and Address Space Limits" you will notice that the virtual memory pool is fixed in older (non 64-bit) versions of Windows. Since many applications and drivers dip into this limited pool, the pool can become depleted. When there is no water left in the pool, then none of the kids can play. (None of your processes can function, including explorer.exe that renders the desktop that you see.)

    Drivers appear to play a huge role in this problem for Windows Server 2003 32-bit. For instance, I have documented dozens of cases where I have restored an image of a W2K3 physical server with no history of GSOD problems into an ESXi VM, and then experience daily lockups when the backup runs. The main difference between the physical server and the VM? Drivers. The VMWare Tools (again, imo) seem to consume more virtual memory than the Dell drivers that were previously installed. In fact, the problem with image based backups and the GSOD has become such a routine problem for us that we now refuse to virtualize W2K3 32-bit.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: daniel@l1n.com
  • Since we had these GSOD in the past we have disabled VSS on our BUDR backups. Has anyone ever had the GSOD on Server 2008 (32 or 64bit) with VSS enabled for the backups?

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: Coldfirex
  • Just reporting in that with VSS disabled the backup runs fine for weeks.

    Re-Enabled VSS for one backup, and the server locked up...
    have applied microsoft VSS hotfixes, and using BUDR 9.7

    not good Sad

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: AltairSystems
  • I had posted previously that 9.7 seemed to clear up this issue but alas, it has not. daniel@l1n.com seems to at least provide an answer whereas Kaseya ("issue? what issue?") and Acronis have not been able to do. Anyone know for sure what kind of memory we need to monitor to prevent a complete depletion? I asked support this question as well. I suspect I'll get an answer here first.

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: support@hdtech.com
  • Anybody ever seen a VM GSOD from enabling VSS with BUDR?

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: Coldfirex
  • Coldfirex
    Anybody ever seen a VM GSOD from enabling VSS with BUDR?


    Yes it is happening to us with ESXi 4

    Legacy Forum Name: BU-DR,
    Legacy Posted By Username: TITaN
  • daniel@l1n.com
    This is purely my opinion, so take it with a grain of salt....

    I have seen many image based backup solutions (including Acronis and BESR) suffer from the GSOD. My opinion is that this is not a bug in the backup products; the problem lies in the way that Windows Server 2003 utilizes virtual memory.

    I make heavy use of both BESR and Acronis. I have some servers that experience this GSOD problem daily, and others that do not experience it at all. I would like to point out that I have not had a single GSOD under Windows 2008 (32 or 64-bit) or Windows 2003 64-bit. I believe the reason for this is that newer operating systems have access to a larger pool of virtual memory (paged, nonpaged, etc). Reference the following MSDN article:

    http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx

    If you look at the chart titled "Memory and Address Space Limits" you will notice that the virtual memory pool is fixed in older (non 64-bit) versions of Windows. Since many applications and drivers dip into this limited pool, the pool can become depleted. When there is no water left in the pool, then none of the kids can play. (None of your processes can function, including explorer.exe that renders the desktop that you see.)



    This is also the exact conclusion we came to. Non-paged memory dries up and everything halts (gray screen of death). Though, this is a bug in Acronis because the way they dirty up the memory.

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