locked
Backup disk space not being recycled RRS feed

  • Question

  • Hi, I hope someone can help me resolve this problem. I run multiple Server 2008 R2 backup jobs to dedicated SAN disks that are attached to my servers using iSCSI. As I understand it Windows Server Backup should manage the copies it stores such that if the target backup storage disk runs out of space it will start to overwrite the oldest backups. Therefor keeping a rolling number of copies which is just what we need. This appeared to be working well and all my backup storage disks are full however recently I noticed one of the four jobs had stopped working. The event log reports: ID 546

    The backup operation attempted at '‎2012‎-‎01‎-‎27T21:02:15.446810400Z' has failed to start, error code '2155348040' (There is not enough free space on the backup storage location to back up the data.). Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.

    I dont understand why it would report this? There are 4 complete backup copies in the catalog on this disk but now it stops recycling old space?

    Thanks for any help with this.

    Paul

    Monday, January 30, 2012 10:08 AM

Answers

  • Hi

     

    The error code 2155348040 indicates BLB_E_BACKUP_TARGET_SPACE_NOT_ENOUGH which happens if the target volume size is not sufficient to create a backup. In your case the total used space of source volume(s) could be greater than the space on the target volume.

    So please check the free and used space on the source volumes and retry the backup with the target volume space greater than that total space. We recommend the target volume size to be 1.5 times of the total size of all the source volumes for scheduled backups so that you can have sufficient number of backup versions stored.

    If you are using Block Level Backup then one other possibility could be that your source volume is fragmented causing the backup size to be more than expected. If that is the case then retry the backup after defragmenting the source volume.

     

    By the way, it is recommended that you read the following blogs.

     

    Automatic Disk usage management feature comes into play when Windows Server Backup detects that the backup target does not have enough space to accommodate the backup while backup is in progress. The way Windows Server Backup creates space for new backup is by shrinking the storage space allocated for snapshots (called diff area). As a result, one or more older snapshots (and hence backup versions corresponding to those snapshots) occupying the diff area that got shrunk get deleted. Before shrinking diff area, WSB determines whether shrinking the diff area can free up the requisite space so the backup can happen. If enough free space can get created, WSB goes ahead with the shrinking and continues with the backup.  WSB will not shrink the diff area to less than 1/8 of Target volume size as we do not want to lose all past backups just to accommodate this one. This is why sometimes backup fail with target out of disk space in spite of automatic disk usage management feature in Windows Server Backup.

     

    For more details, please refer to:

     

    Windows Server Backup automatic disk usage management

    http://blogs.technet.com/b/filecab/archive/2011/03/14/windows-server-backup-automatic-disk-usage-management.aspx

     

    Backup Version and Space Management in Windows Server Backup

    http://blogs.technet.com/b/filecab/archive/2009/06/22/backup-version-and-space-management-in-windows-server-backup.aspx

     

    Best regards,

    Jeff Ren


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Jeff Ren Tuesday, January 31, 2012 9:37 AM
    Tuesday, January 31, 2012 4:54 AM

All replies

  • Hi

     

    The error code 2155348040 indicates BLB_E_BACKUP_TARGET_SPACE_NOT_ENOUGH which happens if the target volume size is not sufficient to create a backup. In your case the total used space of source volume(s) could be greater than the space on the target volume.

    So please check the free and used space on the source volumes and retry the backup with the target volume space greater than that total space. We recommend the target volume size to be 1.5 times of the total size of all the source volumes for scheduled backups so that you can have sufficient number of backup versions stored.

    If you are using Block Level Backup then one other possibility could be that your source volume is fragmented causing the backup size to be more than expected. If that is the case then retry the backup after defragmenting the source volume.

     

    By the way, it is recommended that you read the following blogs.

     

    Automatic Disk usage management feature comes into play when Windows Server Backup detects that the backup target does not have enough space to accommodate the backup while backup is in progress. The way Windows Server Backup creates space for new backup is by shrinking the storage space allocated for snapshots (called diff area). As a result, one or more older snapshots (and hence backup versions corresponding to those snapshots) occupying the diff area that got shrunk get deleted. Before shrinking diff area, WSB determines whether shrinking the diff area can free up the requisite space so the backup can happen. If enough free space can get created, WSB goes ahead with the shrinking and continues with the backup.  WSB will not shrink the diff area to less than 1/8 of Target volume size as we do not want to lose all past backups just to accommodate this one. This is why sometimes backup fail with target out of disk space in spite of automatic disk usage management feature in Windows Server Backup.

     

    For more details, please refer to:

     

    Windows Server Backup automatic disk usage management

    http://blogs.technet.com/b/filecab/archive/2011/03/14/windows-server-backup-automatic-disk-usage-management.aspx

     

    Backup Version and Space Management in Windows Server Backup

    http://blogs.technet.com/b/filecab/archive/2009/06/22/backup-version-and-space-management-in-windows-server-backup.aspx

     

    Best regards,

    Jeff Ren


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Jeff Ren Tuesday, January 31, 2012 9:37 AM
    Tuesday, January 31, 2012 4:54 AM
  • Hi there,

    in my case, the backup disk was far from being full. The error message may be misleading sometimes.

    Just use the DiskShadow-Tool to remove local shadow copies, and try again. In my case, this solved the problem.

    WARNING -  The following action removes ALL SHADOW COPIES and may not be recommended in your scenario. (You can also remove just a subset - take a look at the diskshadow-documentation.)

    diskshadow.exe

    DISKSHADOW> DELETE SHADOWS ALL

    MMF



    • Proposed as answer by secMMF Wednesday, May 16, 2012 11:39 AM
    • Unproposed as answer by secMMF Wednesday, May 16, 2012 11:39 AM
    • Edited by secMMF Monday, May 21, 2012 5:25 AM
    Wednesday, May 16, 2012 11:38 AM
  • Hi there,

    in my case, the backup disk was far from being full. The error message may be misleading sometimes.

    Just use the DiskShadow-Tool to remove local shadow copies, and try again. In my case, this solved the problem:

    diskshadow.exe<o:p></o:p>

    DISKSHADOW> DELETE SHADOWS ALL

    MMF

    This resolved your problem because you have deleted all of the shadow copies in your volume and so you cannot restore data from it... and so this is not a recommended action.

    Please VOTE as HELPFUL if the post helps you and remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, May 16, 2012 2:42 PM
  • Hi,

    I didn't use Shadow Copies, so the solution was ok for me. Sure - someone else may need a different approach, e.g. removing only a subset of shadow copies. The gist of my post was, that the error message is misleading, and that Shadow Copies on the drives, which SHOULD be backed up, may be the culprit.

    I modified my post, as I do not want someone to just give it a try without knowing the consequences ;)

    MMF

    Monday, May 21, 2012 5:23 AM