I just looked into this now. Got a little swamped yesterday. It looks like the 
system is using the OS drive which barely has 19GB free so it's possible that's 
what's tripping it up. I checked the error log & the only errors I'm seeing are 
dropped packets from my RT systems around the time of the backup (which would 
make sense if they aren't stopped). I have a 20GB partition that I can use to 
move the temp tiles to. I'm also going to talk to our VM admin about getting a 
"scratch drive" added. I'm running another PowerShell "grep" on my attachments 
backup file as the sizes from the 18th and the 19th are identical. With the 
volume we do, I don't see how that's possible. The "everything else" .sql file 
shows expected growth.

Stephen Cena
Senior Systems Administrator 
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: hd-gene...@qvii.com
To report email issues: postmas...@qvii.com

-----Original Message-----
From: Jeffrey Pilant [mailto:jeffrey.pilant....@bayer.com] 
Sent: Thursday, January 19, 2017 2:16 PM
To: Cena, Stephen (ext. 300) <s...@qvii.com>
Subject: RE: MySQL backups of RT 4.4.1 truncated

Folder compression can slow things down, but should not cause an issue.

What about temp/scratch space?  If you are making temp files on a different 
disk that is low in space, failure there could cause the problem.  Check the 
free space of all accessible drives, and check where temp files go.

/jeff

-----Original Message-----
Jeff - No limit that I'm aware of. If I look at a VM backup in December, the 
SQL files actually hit 19GB+ versus the "18 and change". The only other 
possibility that it COULD be is I've had to turn on Windows folder compression 
because the backups are getting so large their filling the drive. I could 
temporarily disable it to see if that is factoring into it, but I've bene using 
it all along without issue. The real kicker is I didn't notice the issue soon 
enough  so I'm having difficulty identifying what specifically went wrong.

Stephen Cena

________________________________________________________________________
The information contained in this e-mail is for the exclusive use of the 
intended recipient(s) and may be confidential, proprietary, and/or legally 
privileged.  Inadvertent disclosure of this message does not constitute a 
waiver of any privilege.  If you receive this message in error, please do not 
directly or indirectly use, print, copy, forward, or disclose any part of this 
message.  Please also delete this e-mail and all copies and notify the sender.  
Thank you. 
________________________________________________________________________

Reply via email to