Incremental Backup issue

12 posts / 0 new
Last post
#1 Sun, 03/20/2011 - 01:18
helpmin

Incremental Backup issue

What could trigger that a incremental backup run produces the same size as a full backup?

In my backup log I noticed the following:

13/3: 2.00GB (full) 14/3: 16MB (inc) 15/3: 17MB (inc) 16/3: 2GB (inc) 17/3: 2GB (inc) 18/3: 2GB (inc) 19/3: 2GB (inc)

The question is why the size suddenly changed on 16/3? There were no significant file changes/additions and the database is relatively small. I didn't change any configuration etc

Any ideas?

Sun, 04/10/2011 - 09:30
Isshou

Same thing happened to me today. Incremental backup was full in fact. I tried to make it manually and it was full again.

Then I tried incremental backup of just one domain - still made as full backup. But when I made full backup and then incremental again I have got really incremental. So probably there is lost some information about last full backup and every incremental backup will be made as full till regular full backup is made.

Sun, 04/10/2011 - 09:37
helpmin

Yes, it happens "only once in a while". I haven't been able to reproduce this "at will" though. That is the main reason why I haven't filed a bug report report yet.

Sun, 04/10/2011 - 09:54
helpmin

Yes, it happens "only once in a while". I haven't been able to reproduce this "at will" though. That is the main reason why I haven't filed a bug report report yet.

Wed, 04/13/2011 - 04:03
Isshou

It happens to me after about month running Virtualmin on Debian 5 on OpenVZ. Before this I had Virtualmin on Ubuntu 8.04 on real server for one year with no problem with backups.

I suspect OpenVZ for this problem and maybe low RAM capacity (I had some memory problems those days).

Wed, 04/13/2011 - 10:43
helpmin

I am also on OpenVZ. But I am pretty sure, that it is not memory related (I have plenty).

Wed, 04/13/2011 - 10:52
andreychek

Can you guys post the contents of your /proc/user_beancounters files?

-Eric

Wed, 04/13/2011 - 10:56
helpmin

I don't have this file.

$ cat /proc/user_beancounters cat: /proc/user_beancounters: No such file or directory

Wed, 04/13/2011 - 13:52
Isshou
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
     5273:  kmemsize                 46710940            128596361  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                  975  9223372036854775807  9223372036854775807                    0
            privvmpages                346857               515303               460800               506880                47589
            shmpages                     8419                40817  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0                    0                    0                    0
            numproc                       136                  262                 2000                 2000                    0
            physpages                  280485               435195                    0  9223372036854775807                    0
            vmguarpages                     0                    0               460800  9223372036854775807                    0
            oomguarpages               281666               436365               460800  9223372036854775807                    0
            numtcpsock                     24                  166                 5000                 5000                    0
            numflock                      305                  359                 1700                 2000                    0
            numpty                          1                    8                  256                  256                    0
            numsiginfo                      1                  261                  800                  800                    0
            tcpsndbuf                  420376              3380600              4000000              4050000                    0
            tcprcvbuf                  393216              4016544              4000000              4050000                 1440
            othersockbuf               278288              2454032              4000000              4050000                    0
            dgramrcvbuf                     0               311128               400000               400000                    0
            numothersock                  203                  693                40000                40000                    0
            dcachesize                1637097              2496632              4000000  9223372036854775807                    0
            numfile                      9197                13024  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            dummy                           0                    0                    0                    0                    0
            numiptent                      20                   34                  400                  400                    0
Wed, 04/13/2011 - 14:10
andreychek

Okay, so my rough understanding of OpenVZ memory limits shows that you have nearly 2GB of dedicated memory setup (oomguarpages is 460800, then we multiple that by 4096, which is roughly 1.8GB).

Which is actually quite a bit.

The "privvmpages" is your burst, which is a bit "flaky", in that processes utilizing your burst can be killed to make more RAM available to other users on your VPS.

Now, I'd normally suggest that 1.8GB of dedicated memory is plenty -- but see the failcnt column? That suggests that for "privmpages", that you're seeing some processes being killed off (or not being allowed to spawn at all).

So, something weird is going on, and I'm not sure what or why :-)

You appear to have a lot of RAM, but you're seeing symptoms of memory problems.

If you're seeing a lot of strange issues, or you see that "failcnt" column continuing to increment, you may want to talk to your provider about what might be going on there.

I'm not a OpenVZ guru by any means, but I have read some articles that helped me get my head around all this a bit... two in particular that I found useful are these:

http://maxgarrick.com/understanding-openvz-resource-limits/

http://wiki.openvz.org/Setting_UBC_parameters

Wed, 04/13/2011 - 14:57
Isshou

Thanks, very useful information. I am not sure if failcnt is persistent between server reboots. I mean - I have started with less memory than 1800 MB I have now. I am increasing it when I see some memory errors in log file. So if failcnt won't reset by server reboot then it's "ok" :-) , I had those problems with about 1500 MB. But if it does reset (I have rebooted server since last memory problems) then I will check it.

Anyway I will read more about OpenVZ memory management. Thanks again.

Thu, 04/14/2011 - 03:27
helpmin

I don't think though that a lack memory triggers a full backup which completes successfully - whike no other services are interrupted :-)

Topic locked