Hi all, happy New Year and thanks in advance for your help.

I've been running Reflect for 5 years and have been very happy with it. Recently one of my backups has been failing. I'm using Reflect Home v8.0.7175 on a Windows 7 machine and trying to image a 2.44 Tb drive that has 576.77 Gb of used space. The 10.7 Tb backup volume has 2.75 Tb free, but the backup fails with the error "Backup aborted! - Write operation failed - There is not enough space on the disk.". All of my other backups (I have 9 total jobs on 4 different Windows machines) are running fine (many occur every night) and write to the same backup drive.

I've read similar posts in this forum and so far have not been able to find my solution. For example, I do not have another backup software running at the same time, and no other Reflect backups are scheduled when this backup occurs. I'm careful to make sure their run times don't overlap and no backup starts until the previous backup has finished. For example, the backup that is failing takes 2-3 hours to run, and has a 3.5 hour backup window when no other backups are running. It is my largest backup by a factor of 3.

The only thing that I can think of is that the backup volume is a Linux box with six 2 Tb drives. Maybe Reflect has an issue writing the backup image across multiple physical drives in a spanned volume?

I tried to attach the log file but the upload keeps timing out so I've pasted it below. I look forward to your telling me what I've missed!

***********************************
Image ID - D685C80EDFCA0ED0
Imaging Summary
    Backup Definition File:    C:\Users\admin\Documents\Reflect\Backup_KaigenD.xml
    Auto Verify:    N
    Verify File System:    Y
    Maximum File Size:    Automatic
    Compression:    Medium
    Password:    N
    Intelligent Copy:    Y
    Power Saving:    N
    Email On Success:    N
    Email On Warning:    Y
    Recipients:    [email protected]
    Email On Failure:    Y
    Recipients:    [email protected]
    Total Selected:    576.77 GB
    Current Time:    1/2/2023 12:00:36 AM
Destination
    Backup Type:    Full
    File Name:    \\192.168.1.20\Backups\Backups\Backup_KaigenD\Kaigen_D-00-00.mrimg
        Attempting to connect to: '\\192.168.1.20\Backups\Backups\Backup_KaigenD'
        Successfully connected
Operation 1 of 1
    Hard Disk:    2
    Drive Letter:    D
    Volume:    \??\Volume{1b1fbc49-8f5e-4aa5-8b69-0f179bc5a09e}
    File System:    NTFS
    CBT:    Y
    Label:    KaigenD
    Size:    2.44 TB
    Free:    1.87 TB
    Used:    576.77 GB
Starting Image - Monday, January 02, 2023 12:00 AM
    Initializing
    Destination Drive:    Free Space 2.81 TB
    Free space threshold:    Delete oldest backup sets when free space is less than 5.00 GB
    
    Creating Volume Snapshot - Please Wait
Volume Snapshots Created
Verifying
    D:\    \??\Volume{1b1fbc49-8f5e-4aa5-8b69-0f179bc5a09e}
Saving Partition - KaigenD (D: )
    Reading File System Bitmap
    Saving Partition
    Gathering Windows Events - Please Wait
Email Notifications
    Recipients:     [email protected]
    Email notification sent
    I/O Performance:    Read 3.1 Gb/s - Write 702.9 Mb/s
    Backup aborted! - Write operation failed - There is not enough space on the disk.

Macrium Reflect Home v8.0.7175

I don’t think a spanned volume on the target would be an issue since Reflect wouldn’t even be able to determine that in a NAS scenario. The underlying storage is abstracted from network clients, and possibly even the OS depending on whether you’re using hardware or software-based spanning. Reflect also appears to correctly identify the free space at the beginning of the job, so something went wrong in the middle of the backup. If this is repeatable, would you be able to log into the Linux box and keep an eye on the reported free space during the backup, just to see if the Linux box itself reports less than expected free space? I’m not actually sure what this will look like on the Linux side, since new files that are still being written aren’t always counted against file system free space figures. But if free space drops well below what would be reasonable for this backup on its own, that would tell you something.

Thanks jphughan for your quick response, and for your thoughts about the spanned storage (it's software-based, BTW) which make sense.

I've talked to my boyfriend and we'll put together a bash script to write the free disk space that the NAS reports to a log file once a minute during the backup. Then we can see if it shows any dramatic drops in free space. I'll post an update once I have that info.

Hi jphughan et al, thanks again for your help.

The backup I've been having trouble with failed again overnight, so I tried running it today when I could watch it more closely. It ran for approx. 1.5 hours then failed with the same error message "Backup aborted! - Write operation failed - There is not enough space on the disk." I believe the job was ~80% completed when it failed.

Looking at the log file that we generated while the backup ran, the drive reached 79% used shortly before it failed, meaning, out of an 11Tb JBOD drive, 8.0Tb was used and 2.3Tb was free. Up until that point, the drive usage started at 74% used (2.8Tb free) and slowly crept up to 79% used (2.3Tb free). I can send the entire log file if you think it would be helpful.

Wed Jan 4 14:34:32 EST 2023
JBOD-Backups 11T 7.5T 2.8T 74% /mnt/backups
.........
Wed Jan 4 16:07:32 EST 2023
JBOD-Backups 11T 8.0T 2.3T 78% /mnt/backups
Wed Jan 4 16:08:32 EST 2023
JBOD-Backups 11T 8.0T 2.3T 79% /mnt/backups

 Is it possible to capture more verbose logging for Reflect? Any thoughts about what else I can investigate?

Thank you!

Hey April,

Sorry you're still having trouble. I don't know of a way for end users to get more verbose logs out of Reflect, but Macrium is certainly able to do so, and I've worked with them to chase down bugs using my system as a test case.  In terms of your error, if my memory from previous posts by Macrium Support on this forum is accurate, Reflect relies on standard Windows APIs to write to network locations (and local disks, for that matter), and it's even possible that the free space error message is an error that was actually thrown by Windows and passed up to Reflect, which it's then displaying, as opposed to an error generated by Reflect itself.  My main suggestion at this stage would be to see if Macrium themselves respond here -- fyi the Macrium Support reps who are active on this forum are the actual developers, not typical customer service reps with little to no technical training -- or else open a formal support ticket with them if you don't get a response quickly here.  They tend to respond very quickly and helpfully, especially if you're able to work with them to gather more information from your system.  And if the cause does turn out to be something with Reflect, a update to resolve that issue typically arrives very shortly thereafter.  My gut says that this might come down to some sort of protocol-level glitch that leads to inaccurate free space reporting, but I definitely don't know for sure. Linux isn't my forte.  But out of interest, is your Linux box on the latest kernel release just in case there might be glitches of that kind?  Good luck!

EDIT: Never mind. Underlying cause in the thread linked below was identified and resolved.

@renarde Well as soon as I finished that reply, I checked the other newly updated thread in this section and found that it reports a problem that seems very similar to yours. Here is the direct link.  Perhaps there's something on the Reflect side of this equation after all.  Hopefully one or both of you can work with Macrium to help them understand underlying cause and identify a fix.

It looks like the author of the "Problem Imaging a 4tb drive to a Western Digital Cloud Server" realized that he had mistakenly set up the backup that was failing to use a drive with insufficient space. You've been kind enough to help me confirm that's not what's going on in my case.

At this point, unless one of the Macrium devs chimes in with another perspective, it seems I'll need to open a support ticket with Macrium so they can dig into the logs and see if there is truly some sort of protocol-level glitch.

Hi @renarde, 

The message "There is not enough space on the disk" is an error received from Windows via the network share OS and normally indicates that a disk quota has been exceeded.

It isn't the same error as the disk being full, and the reason will possibly be a file system/user configuration, or some such. You'll likely receive the same error if the same amount of data is copied to the share using Windows explorer.

Kind Regards

Joe A

Macrium Support Team

See our reviews on

+x

 

Joe Allen - 5 January 2023 10:58 AM

Hi @renarde, 

The message "There is not enough space on the disk" is an error received from Windows via the network share OS and normally indicates that a disk quota has been exceeded.

It isn't the same error as the disk being full, and the reason will possibly be a file system/user configuration, or some such. You'll likely receive the same error if the same amount of data is copied to the share using Windows explorer.

@JoeA, thanks, I appreciate your quick response. I have a couple of questions before I explore other options on my own. As far as you know, is there a limit to how much data a single Reflect backup job can handle, meaning, have I reached the operating limit of the software? Based on other tickets or internal Macrium knowledge, is there a maximum amount of data that a single job can back up? Just wondering.

It sounds like I have two possible options from here:
1) Educate myself about how Windows reads and handles disk quotas when the storage volume is a Linux NAS to see if I can figure out the problem.
Or
2) Divide the content of my main document and music storage drive into two backups instead of one monstrous job, and see if that helps.

Thanks again

I've seen people successfully back up 10 TB of source data in a single Reflect backup job, so even if that's the limit -- which I have no reason to believe it is -- you're nowhere near it.

Any quotas relevant to this scenario would be configured on the Linux side, since that's the side managing the storage.  Essentially they give you a way to say that a certain user is only allowed to store X amount of data on a volume, and once the total size of files stored by that user reaches that limit, any applications using that user's account to write more data are told that there's no more capacity, which is the error you're seeing.  (And now that Joe has posted that, I'm over here smacking my forehead for having been a Windows IT guy for 15 years and having quotas come up on various certification exams over the years, and not having thought of it here. )