Comprehensive data protection for all workloads
mrt
Enthusiast
Posts: 47
Liked: 2 times
Joined: Feb 10, 2011 7:27 pm
Contact:

backups writing to C:\Windows\SysWOW64

Post by mrt » Dec 05, 2011 3:08 am

Why might my backups be suddenly writing to C:\Windows\SysWOW64 when this directory is not specified in the backup repo node? Other volumes specified in the node are available and have plenty of free space. Now C: is full and things are failing left and right. These jobs are also affected by the nbd failover bug.

The jobs are configured to make active fulls on the first Sunday of every month, which today happens to be.
I'll get in touch with support but am hoping for a quick answer here. Thanks

kellison
Enthusiast
Posts: 25
Liked: never
Joined: Dec 22, 2009 5:56 pm
Full Name: Ken Ellison
Contact:

[MERGED] Veeam 6.0 Server Hard Drive Space

Post by kellison » Dec 06, 2011 1:28 pm

I upgraded my Veeam server to 6.0 over the weekend - it is a VM Windows 2008 R2 server. Upgrade went well but last night was the first rn of backups. I had about 10 GB of hard drive space available on my "C" drive when I left for the day. The Veeam is installed on this drive. This morning I found that over half my backups had failed. Looking at the event logs I found out the "C" drive had run out of hard drive space. I then shut down the server and added 20 more GB to the "C" drive, and proceeded to run a backup. It is at 29 percent (running VERY SLOW) on the first VM of 6 and it has already used up 10 GB of hard drive space. What is causing this and how to I fix this? My retention period for my backups is 7 days.
HELP !!!

engagingit
Lurker
Posts: 1
Liked: never
Joined: Dec 06, 2011 1:37 pm
Full Name: Allan Napier
Contact:

Re: Veeam 6.0 Server Hard Drive Space

Post by engagingit » Dec 06, 2011 1:39 pm

Happening to me as well, a copy of the backup file is being made at c:\windows\syswow64

I'm assuming there is a flag to make it write directly to the usb drive rather than save locally first but I can't seem to find it.

real_tarantoga
Enthusiast
Posts: 56
Liked: 6 times
Joined: Aug 20, 2009 12:32 pm
Location: Germany
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by real_tarantoga » Dec 06, 2011 1:40 pm

My veeam Backup Server is updated - and no more usable. :(
No way to disable excessive writing into %windir%\syswow64? (not resolved)
No way to chose the default repository while upgrading? (resolved)
A really annoying bug with the "synthetic full" check box! (resolved)

... and why a default repository on %systemdrive% ?!? What happens to veeam?

looking at your answer with anticipation, Stefan :wink:

kellison
Enthusiast
Posts: 25
Liked: never
Joined: Dec 22, 2009 5:56 pm
Full Name: Ken Ellison
Contact:

Re: Veeam 6.0 Server Hard Drive Space

Post by kellison » Dec 06, 2011 1:45 pm

Update - I had to stop my backup - it used up the entire 20 GB that I had added....

Vitaliy S.
Product Manager
Posts: 22311
Liked: 1415 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by Vitaliy S. » Dec 06, 2011 1:48 pm

Please contact our technical team as logs investigation is required. Thanks!

Gostev
SVP, Product Management
Posts: 24020
Liked: 3255 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by Gostev » Dec 06, 2011 1:51 pm

real_tarantoga wrote:and why a default repository on %systemdrive% ?!? What happens to veeam?
For consistency, and because usually, there are no other drives. The default repository is for evaluators only, of course we expect that for production usage, customers will create proper repositories pointing to the actual backup storage.

Regarding the actual problem discussed in this topic, we have received only a few reports like this, so this seems to affect very specific configuration of backup server only. Everyone who is affected should open a support case to let us figure out what is common.

Thanks!

real_tarantoga
Enthusiast
Posts: 56
Liked: 6 times
Joined: Aug 20, 2009 12:32 pm
Location: Germany
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by real_tarantoga » Dec 07, 2011 11:25 am

short status update

the support recommandation to use another backup proxy was almost right, but ... also 64bit backup proxies didn't work.
i tried on a 32bit server - and it was running.
I will now create a backup proxy server pool on an dedicated esx host cluster (DRS disabled), with 2003 r2 & 2008 r1 enterpise servers, giving them a lot of vCPUs ... and i will update my results here.

for now it seems to be an explicit 64bit problem.

Stefan

Sethbartlett
Expert
Posts: 282
Liked: 25 times
Joined: Nov 10, 2010 6:51 pm
Full Name: Seth Bartlett
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by Sethbartlett » Dec 07, 2011 1:34 pm

You can also try deleting your current repository and creating a new one pointing to the same location and updating the job, this has seemed to work.
Skype: Sethbartlett88 - Make sure to label who you are and why you want to add me ;)
Twitter: @sethbartlett
If my post was helpful, please like it. Sometimes twitter is quicker to hit me up if you need me.

Gostev
SVP, Product Management
Posts: 24020
Liked: 3255 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by Gostev » Dec 07, 2011 1:42 pm

Must be related to automatic creation of repositories during the upgrade.

real_tarantoga
Enthusiast
Posts: 56
Liked: 6 times
Joined: Aug 20, 2009 12:32 pm
Location: Germany
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by real_tarantoga » Dec 08, 2011 3:36 pm

Hello board,
the workaround with virtual machines used as backup proxies was very successful.
Even more I could run more concurrent jobs as anytime before! No real stress or heavy performance impact neighter on the VMs nor on the two ESX servers. So veeam jobs have processed the backup for 100 VMs over night - some uncounted terra bytes ... That's cool.

Other than mentioned above I could also use x64 machines.
The problem wasn't related to the architecture but to a mishandling of the existent backup jobs and/or backup files on the imported backup repository during the upgrade process.

The backup proxy on the upgraded veeam b&r 5.0.2.255:
  • works for all newly created jobs - it is not possible to map old vbk files to the new jobs, so I have to start with a full backup.
  • doesn't work for any job with exisisting vbk/vbr files, works after removing the backup files through the GUI
  • doesn't work for old jobs with german vowels (umlauts) - even if the manually given file name doesn't include umlauts! - and works when the jobs will be renamed. That always worked in the older program versions ...
  • doesn't work for jobs (vbm+vbk) moved from syswow64 to the backup repository, backups must be deleted
I wonder why the program continues to use the %systemroot%\syswow64 folder to put the meta file here for only some jobs, while other (new) jobs create subfolders on the repository and another group of jobs put the meta file right beside the existing vbk files ...

Finally, the problem seems to be resolved by working around step by step from issue to issue - and losing a lot of backups!!!
For the first time I'm deeply disappointed with the software and also with the support - not with the reaction time, but with the given answers and result (there's no solution or lossless workaround until now). I've got the impression they were "groping about in the dark" (?) as well.

Regards, Stefan

Gostev
SVP, Product Management
Posts: 24020
Liked: 3255 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by Gostev » Dec 08, 2011 3:51 pm

Hi Stefan, sorry for the issue you've experienced. I have forwarded your feedback to our support and QC management. I've also verified that the issue is not wide spread (just a few support cases). With any software, there is always a risk with running into issues when making a decision to upgrade to the new major release immediately upon its availability. It is fair to say that no amount of testing by limited QC group can cover all the configuration and upgrade scenarios our 35'000 customers might have. Thanks.

kellison
Enthusiast
Posts: 25
Liked: never
Joined: Dec 22, 2009 5:56 pm
Full Name: Ken Ellison
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by kellison » Dec 08, 2011 7:27 pm

I have to agree with Stefan - after going back and forth with support for a whole day - "try this - try this" I finally gave up and created a new datastore, added it as a new drive letter to my Veeam VM server, deleted the backups and repository and basically started from scratch again on my backups. Strange though that my other repository that was brought over from the upgrade is working fine. In fact, I had 2 different backups in the repository that I had deleted and the other backup worked fine. On my DR site that was also upgraded I am not having any trouble with the repositories (so far)... I'm not seeing any huge improvement in speed but guess will just be thankful that I have the backups working again.

flavor4real
Expert
Posts: 205
Liked: 5 times
Joined: Nov 22, 2010 7:57 pm
Full Name: DS
Contact:

[MERGED] vbk get push to a different path

Post by flavor4real » Dec 04, 2012 2:04 pm

Hello,
How is it going? All of my Veeam jobs worked fine until now. All of the sudden the one backup job creates their vbk in c:\windows\SysWOW64\

There were no prior issues with veeam and I'm kind of wondering. I already removed the VBK, verified the veeam job setting and tested again. Still does the same

Thanks

Gostev
SVP, Product Management
Posts: 24020
Liked: 3255 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: backups writing to C:\Windows\SysWOW64

Post by Gostev » Dec 04, 2012 7:39 pm

Hi, what product version are you running? This sounds like known v5 upgrade issue that was resolved loooooooooooong ago... I believe, in 6.1 release.

Post Reply

Who is online

Users browsing this forum: cfortenbery, ctalbot, foggy, gabryp, Google [Bot], ITP-Stan, Karinne, manfri, nmdange, opg70 and 48 guests