Need to Fix "Ran out of Space"


Author
Message
BenR29
BenR29
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)
Group: Forum Members
Posts: 3, Visits: 33
Hello,
I've switched to Macrium recently and I'm not quite used to the way it operates, so please bear with me.
I've had an automated backup setting that has been working successfully for almost a year, but twice this week it has failed with the error "out of space".  Every attempt is a full backup, which is very large for me, so I'm less open to experimenting than normal.

I would attach my log file, but it seems I only have the option to email the logs from within Macrium, I can't find a way to just save them.

My guess is that my source data to be backed up has gotten too large to be compatible with my scheme.  My retention days probably need to be altered, as well as my free space threshold.

My approximate backup size total is about 2 TB backing up to a 5 TB drive with maximum compression.

My scheme is (and I really wish I could copy and paste it as it's displayed, instead I'm using OCR):

Full - At 9:00 AM on the first Mon of every month, starting 5/12/2017
Diff - At 9:00 AM every Mon of every week, starting 5/12/2017
Inc - At 9:00 AM every Mon, Tue, Wed, Thu, Fr of every week, stating 5/12/2017

Retention Rules:
Rules will be applied to all matching backup sets in the destination folder

Full: 
Retain full images for 26 Weeks
Linked incremental and differential images will also be deleted

Differential:
Retain differential images for 4 Weeks
Linked incremental images will also be deleted

Incremental:
Retain incremental images for 14 Days
The oldest incremental images may be consolidated
Purge will be run before the image
Delete oldest backup sets when free space is less than 500 GB
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)
Group: Forum Members
Posts: 4.4K, Visits: 33K
In terms of providing a job log, you can highlight the text of the log in the viewer window and copy/paste it somewhere, or you can right-click the background, select Print, and print it to PDF.  However, with the latter option be aware that your Reflect license key is included at the bottom of every job log, so if you don't have a way to edit a PDF after it's been generated, that might not be ideal.  But your retention policy configuration could have been posted by capturing a screenshot of the wizard view that shows it.  The Snipping Tool built into Windows is useful for this purpose because in addition to letting you draw an arbitrary rectangle, it can automatically capture a particular window.

In terms of your issue, your schedule specifies a Full every month and your retention policy specifies to retain 26 weeks of Fulls, which would be 6 Fulls.  When you say your backup size total is 2TB, I'm not sure if that's the total size of the source data before compression or the size of the compressed backup file that gets generated, but either way you won't be able to store 6 Full backups of that size given your available capacity at the destination, and that's before even taking into account your weekly Diffs and daily Incs.

That said, you do have "Delete oldest backup sets when free space is less than 500 GB" enabled, which would normally prevent jobs from failing due to space issues, because that option allows Reflect to delete the oldest sets even if the free space drops below the specified threshold in the middle of a backup.  So if your backups are failing, I'm thinking some of your old backups might no longer be considered "matching backups" if you recently upgraded to a newer release of Windows 10.  That process can alter your partition map, which means Reflect would consider previous backups not to "match" the new jobs, and therefore by default the retention policy and disk space threshold purge would not be applied to them anymore.  More info about that, including options for fixing it, is available in the first post of this thread.  The easiest fix if you have a destination folder dedicated solely to backups generated by that job (as opposed to a folder that multiple jobs are writing to) is to set the matching policy to "All backups in the destination folder" rather than the default "Matching backups in the destination folder".  In any case, seeing the job log should help determine whether that's what's going on.  In the retention policy section of the job log, Reflect reports the number of matching backups it see on the destination.  If the number of backups Reflect reports is less than the number of backups in the destination folder, that's likely what's going on.

Anyhow, this might also be a good time to rethink your retention policy in general.  First, you generally don't want to rely on the disk space threshold purge as an alternative to specifying a realistic retention policy, because the disk space threshold purge deletes entire SETS when it gets triggered, i.e. the oldest Full and all of its child backups (which would be an entire month of backups in your setup), whereas a retention policy can delete individual child backups.  So again, you may want to take a look at the size of the backup files that are being generated and adjust your retention policy to something that's realistic.  On that front, you might find it easier to switch your retention policy settings to be based on number of backups rather than a period of time.

Edited 26 January 2019 3:01 AM by jphughan
BenR29
BenR29
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)
Group: Forum Members
Posts: 3, Visits: 33
Thank you very very much!  This has been the most informative response I've had to a support question in forever Smile

I did get the "October" Windows update, and I also let my SSD do some space appropriation changes (I'm fuzzy on the details on what it did exactly to my partitions).  Your advice is sound and helpful, I made my retention policy when I was overwhelmed by my options and decided I'd pick the "safest" route, even though that route ended up giving me trouble now.  

I do have a dedicated folder (entire drive actually) for this backup, so I changed the setting to "all backup sets".  The uncompressed source will be at max 2TB, the compression I've seen makes me want to say about a 20% reduction in size.  Either way, it's time to archive some old stuff to offline storage so I can keep more backups of "live" files, I think.

Thank you for explaining the way the disk space threshold deletes SETS, I didn't know that.  I will have to do more research, I hate relying on a single "trunk" for all of my current backups, perhaps I can work something out to keep two trunks at all times...

For now I am confident I will wake up with a completed backup instead of an overnight failure! 
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)
Group: Forum Members
Posts: 4.4K, Visits: 33K
Happy to help! In terms of having a single trunk, there are various ways to address that. Some off the top of my head:

- Use some other application to replicate your backup folder somewhere else.

- One variation of the above strategy would be to periodically clone your backup disk to another disk.

- Use a disk rotation on a weekly or even daily basis so that Reflect writes backups directly to different destinations at different times. This gives you only one copy of any given backup, but it means you’ll always have at least one disk containing backups physically offline and possibly even off-site. Reflect has some options to facilitate this setup in terms of always finding the available destination disk regardless of drive letter, or there are ways to make sure the disks in your rotation always get assigned a consistent drive letter.
BenR29
BenR29
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)
Group: Forum Members
Posts: 3, Visits: 33
Hi, welllllllll once upon a time I had been using a different file imaging software.  The image verification worked for a certain backup set, but it failed to restore when I needed it to, and there was no way to troubleshoot the error. 

So my desire for a second trunk would require a set of bits that were generated at a different time through a different backup process.  At least then, hopefully, the same error would have a smaller chance of being produced twice.  Not impossible, but smaller.

I believe your third option is what I would look for, and I was actually able to rotate my disks before the amount of information I decided to back up became too bloated for multiple cheap disks.  I still have quite the collection of 2TB disks which won't hold a single backup any more.  I could be more picky about what files I backup, but I'm kind of hooked on the idea of complete images.  I could also look at some sort of RAID disk port, but that could introduce a whole other level of complexity.  It's a balancing act.
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)Macrium Evangelist (6.6K reputation)
Group: Forum Members
Posts: 4.4K, Visits: 33K
I don't use the verification option for the simple reason that a successful verification immediately after the backup is absolutely no guarantee that the backup will still be usable when you want to restore from it.  There's plenty of time for file system and/or hardware-level issues to render part of a backup unreadable or corrupt.  In fact, considering that verification wasn't even an option until Reflect V6, my guess is that even Macrium doesn't really think it's particularly useful and only implemented it in response to customer requests to remedy a perceived competitive deficiency, possibly figuring that it was easier to simply give the people what they want rather than educating them as to why it wasn't actually necessary.  Macrium's own KB article about verification says that they estimate that fewer than 1 in 1000 systems (not backups) will ever experience a verification error.

Anyway, I have a few clients that use daily or weekly disk rotations.  In their cases, for a variety of reasons I opted to use a separate utility (USB Drive Letter Manager) to ensure that all destination disks consistently receive a particular drive letter when they're connected, so the Reflect setup just targets a particular drive letter, but if you don't want to rely on a separate utility, switching Reflect to use volume identifier-based destination discovery (Edit Defaults > Advanced > Destination Discovery) and then using the Alternative Locations feature in the definition file settings will achieve the same end result.

As for RAID, I would only recommend that if you'd be installing your disks into some sort of enclosure with built-in RAID support so that it can mount on PCs as a typical hard drive.  If you want to contemplate installing an actual RAID controller and connecting your disks to that, make sure you won't ever need to access those backups without that controller, because importing disks that were set up by one RAID controller onto another one is sometimes possible, but nowhere near guaranteed to work, and in general the last thing you want in a disaster situation is to face additional complications trying to access your backups.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search