Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Borg check freezes the low-powered server #8603

Open
rolandu opened this issue Dec 26, 2024 · 2 comments
Open

Borg check freezes the low-powered server #8603

rolandu opened this issue Dec 26, 2024 · 2 comments
Labels

Comments

@rolandu
Copy link

rolandu commented Dec 26, 2024

Have you checked borgbackup docs, FAQ, and open GitHub issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Question

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

  • Server: 1.1.16
  • Client: 1.2.8

Operating system (distribution) and version.

  • Server: Debian 11, Linux 5.10.0-32-amd64
  • Client: Mint 22, Linux 6.8.0

Hardware / network configuration, and filesystems used.

  • Server: Mini PC, Intel Celeron N3000, 8 GB RAM, HDD, zfs
  • Client: Laptop, Intel Core 7 Ultra, SSD, 64GB RAM, ext4

Client and Server are on the same local network / wifi.

To summarize: This is a high-end laptop trying to backup to a low-end "server" (i.e. NUC-clone mini-pc).

How much data is handled by borg?

~600 GB

Full borg commandline that lead to the problem (leave away excludes and passwords)

borgmatic check --force

borgmatic config:

checks:
    - name: repository

this runs:

borg check --repository-only --debug --show-rc --progress

Describe the problem you're observing.

On the client machine I can monitor the progress of the check, which is about 10% per hour.

Meanwhile I am observing lots of errors on the server machine relating to other processes being out of memory, returning error 500, etc. (I am running some services on the same server).

Even after cancelling the check client-side, the server is still unresponsive. Half an hour later, I was able to log in via ssh and kill the borg process on the server, which was hogging 20% of CPU and lots of RAM.

Questions:

  • Could it be that my server is simply too underpowered to run the checks properly?
  • Is there a way to limit the system resources the server's borg process uses, e.g. limit to 2GB RAM?
  • Could running borg via sshfs instead of ssh reduce this problem, as I am not using the server's borg process?

Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.

Yes, happens every time I try to perform a check.

Include any warning/errors/backtraces from the system logs

N/A; can provide CRUD benchmark if it's considered relevant.

@ThomasWaldmann
Copy link
Member

borg serve needs some RAM because it loads the repo index into memory (and no, there is no way to "limit" that except using repositories with less chunks in them and thus having a smaller repo index). There is a formula in the docs to estimate the RAM usage.

but 8gb should usually be enough to run borg, so there might be some other issues:

  • is zfs using lots of memory? you can limit the l2 arc memory usage, the default might not be the best if you don't have lots of RAM.
  • other services taking a lot of these 8GB? maybe you can use some time slot at night or early morning to shut these down while you run borg operations, like backups, checks.
  • if your RAM is upgradable: RAM is cheap. :-)
  • if nothing else helps: add more swap (and maybe avoid swapping on zfs). it will be very slow if you use more memory than ram, but it might help with processes not getting killed.

You could also upgrade the borg running on the server (see debian backports), but I guess it won't help with the RAM usage, but give you some other improvements.

@ThomasWaldmann
Copy link
Member

Running via sshfs is usually slower (more network traffic) and might have its own issues (like many network fs have), but yes, it would shift the borg memory usage from the server to the client.

I would first try the other options, see previous post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants