Re: [rt-users] MySQL backups of RT 4.4.1 truncated

[Cena, Stephen (ext. 300)]

All the backups I'm doing are local to keep performance high. I sadly lost the 
"discussion" to keep the MySQL server on a Linux machine. What we're going to 
try is the following:
We're snapshotting/backing up the system at regular intervals so I will always 
have a backup of the .sql files. I'm going to move the MySQL TMP folder to the 
larger drive to see if that solves the issue. I think you might be on to 
something with the drive issue as it looks to be the only consistent factor. 
I'll update as I know more.

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: Friday, January 20, 2017 8:54 AM
To: Cena, Stephen (ext. 300) 
Subject: RE: MySQL backups of RT 4.4.1 truncated

Just FYI:
When windows copies files between drives, I believe it copies them to a temp 
area first before copying the temp area to the destination.
It probably does this to avoid writing a partial file when running out of 
space.  Because it causes a doubling of data transfer, it is stupid, but then, 
it is Microsoft Windows.

If your backup process includes copying the result across drives, this could be 
the source of the problem.

/jeff

Re: [rt-users] MySQL backups of RT 4.4.1 truncated

[Cena, Stephen (ext. 300)]

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) 
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.