profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ThomasWaldmann/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
TW ThomasWaldmann Earth, Solar System, Local Interstellar Cloud, Local Bubble, Orion–Cygnus Arm, Milky Way

borgbase/vorta 991

Desktop Backup Client for Borg

tayfunulu/WiFiManager 188

WiFi manager for ESP8266 - ESP12 - ESP32 - micropython

moinwiki/moin-1.9 107

MoinMoin Wiki (1.9, also: 1.5a ... 1.8), stable, for production wikis

ThomasWaldmann/py-esp32-ulp 52

ESP32 ULP Co-Processor toolchain implemented in MicroPython

python-llfuse/python-llfuse 41

Python bindings for the low level FUSE API

ThomasWaldmann/argparse 41

python argparse, pypi version (moved from google code)

ThomasWaldmann/borg 9

this is my personal repo, the main project repo is there: -->

discorporate/flatland 6

HTML form management, schema validation

ThomasWaldmann/nsupdate.info 2

Dynamic DNS service

ThomasWaldmann/pretalx 2

pretalx fork to merge hackathon changes, do PRs against vcc branch

issue commentborgbase/vorta

Apple Silicon (M1, ARM) support

Hmm, just noticed that the vorta app (installed via brew cask) is an intel binary, so on M1 cpus it will require rosetta translation.

Can this be solved easily, like making some "dual mode" binary or so?

If I directly invoke the system python3, I see that is a native m1 binary, so it's not the system python at fault.

LukeWheeldon

comment created time in a day

issue openedborgbackup/borg

borg delete --force should kill repo without passphrase

There should be a way to cleanly remove a repo even if the passphrase was lost.

borg delete wants to know the passphrase (and if given, it will list all archives in the repo and ask "are you sure?"). to list the archives, the key is needed, so it wants the passphrase.

But if the user is really sure anyway, we could offer a non-default less safe way with --force and just killing the repo, no questions asked.

Workaround until this is implemented:

borg config REPO id     # gives id for manual clean up
rm -rf REPO
rm -rf ~/.cache/borg/THATID
rm -rf ~/.config/borg/security/THATID

created time in 2 days

issue commentborgbackup/borg

ACL code does a lot of user/group<->uid/gid lookups

I guess we rather should fix this in borg 1.2, it's quite likely it needs a bigger / critical change to the code.

biji

comment created time in 2 days

issue commentborgbackup/borg

borg stumbles over "Segment entry checksum mismatch" in archives check

Guess I'ld need to do debugging on a system where this is happening.

shelvacu

comment created time in 2 days

issue commentborgbackup/borg

opencollective.com

@m3nu @jfdh ok, hopefully this is correct, i put "Open Collective Europe" there.

So, there is currently nothing I could do more on https://github.com/sponsors/borgbackup/dashboard or at stripe.

  • "Complete the required documentation to receive payouts" is still marked as not done, but if I click, I can't do anything there.
  • "We’ll assign you a tax form once and your Stripe account is verified" is still marked as not done, but the tax stuff is done by github and OC EU anyway, not me.

Thus, I can still not click on "request approval".

ThomasWaldmann

comment created time in 2 days

pull request commentborgbackup/borg

fix xxh64 related build

https://salsa.debian.org/debian/borgbackup/-/blob/master/debian/patches/bundled-xxhash.patch

ThomasWaldmann

comment created time in 4 days

pull request commentborgbackup/borg

fix xxh64 related build

Hmm, looks good, but does not compile. :-( @LocutusOfBorg any idea?

I also tried adding that XXH_PRIVATE_API, but that doesn't help either.

I am also wondering: what was the reason for your patch, I did not see a bug report, neither did I have a build issue myself with the 1.1.17 code.

ThomasWaldmann

comment created time in 4 days

PR opened borgbackup/borg

fix xxh64 related build

@LocutusOfBorg this is inspired by the "fix existing code" part of your debian patch.

changes:

  • the ".../xxh64" path part was missing in your patch.
  • i changed the wrong part of the code rather (in your patch, you did not touch this)
+5 -4

0 comment

1 changed file

pr created time in 4 days

delete branch ThomasWaldmann/borg

delete branch : remove-fuse-version-check-1.1

delete time in 4 days

push eventborgbackup/borg

Thomas Waldmann

commit sha 92a4ab461604455737dff40afad7c664ccf7796a

fuse: remove unneeded version check and compat code we require >= 1.3 now anyway, see setup.py.

view details

TW

commit sha 3044a343cf469ed99583002a80e65fa4cd84c5c8

Merge pull request #5936 from ThomasWaldmann/remove-fuse-version-check-1.1 fuse: remove unneeded version check and compat code

view details

push time in 4 days

PR merged borgbackup/borg

fuse: remove unneeded version check and compat code

we require >= 1.3 now anyway, see setup.py.

Looks like this was forgotten to backport to 1.1-maint and also was a remainder still requiring distutils.

Thanks to @LocutusOfBorg for pointing to the right changeset in master.

+4 -9

1 comment

1 changed file

ThomasWaldmann

pr closed time in 4 days

create barnchThomasWaldmann/borg

branch : fix-xxh-build-1.1

created branch time in 4 days

push eventThomasWaldmann/borg

Thomas Waldmann

commit sha 92a4ab461604455737dff40afad7c664ccf7796a

fuse: remove unneeded version check and compat code we require >= 1.3 now anyway, see setup.py.

view details

push time in 4 days

push eventThomasWaldmann/borg

Thomas Waldmann

commit sha 66afc0c795eca2cf3f25f93e0128406b9011bef6

fix pep8

view details

push time in 4 days

PR opened borgbackup/borg

fuse: remove unneeded version check and compat code

we require >= 1.3 now anyway, see setup.py.

Looks like this was forgotten to backport to 1.1-maint and also was a remainder still requiring distutils.

Thanks to @LocutusOfBorg for pointing to the right changeset in master.

+2 -9

0 comment

1 changed file

pr created time in 4 days

issue commentborgbackup/borg

ubuntu 21.04, ubuntu 21 and ubuntu 20.10 crashing

@GameTec-live if the repo files are just owned by the user you use for the borg ssh login, you won't have owner or mode issues. Some people like to add a "borg" user (and group) just for that.

And never use 777 for anything except if you know what you do.

GameTec-live

comment created time in 4 days

create barnchThomasWaldmann/borg

branch : remove-fuse-version-check-1.1

created branch time in 4 days

push eventThomasWaldmann/borg

Thomas Waldmann

commit sha 9db019f75cbc1a5650bd8556e27423b6c545852c

update CHANGES

view details

Thomas Waldmann

commit sha 6c0a09d12c763c5ba425c8f87cc00f1a818fe2f4

vagrant: fix run_tests for py310

view details

Thomas Waldmann

commit sha fc3b7fdad10f6b5eaad97b77cff1ad2138903498

build_usage

view details

Thomas Waldmann

commit sha fdc0743457085566327dd8ce6f627999d4a5cf57

build_man

view details

TW

commit sha 8336b000f3e8dcb4e55b3538fa345e2bc22468b6

Merge pull request #5920 from ThomasWaldmann/rel1117 release 1.1.17

view details

Tommy Nguyen

commit sha d91c34f1132f084c8fe98d535cb102210ac5c8b0

docs: fix sphinx warnings Fixes: #5919

view details

Tommy Nguyen

commit sha 928347bd89bc7b454d6de70d018a3c69267b8f56

docs: remove duplicate faq entries Fixes: #5926

view details

TW

commit sha 6b8c369903af515882fbc47a02ba33a518a070b9

Merge pull request #5931 from remyabel/docs-fix-duplicate docs: remove duplicate faq entries

view details

TW

commit sha b4b1c403a110f7bcb97bdd4bb21edae719d24ea7

Merge pull request #5930 from remyabel/docs-fix-warnings docs: fix sphinx warnings

view details

push time in 5 days

issue commentborgbackup/borg

update docs bounty (44)

@rpolley thanks!

ThomasWaldmann

comment created time in 5 days

issue commentespressif/arduino-esp32

After 1.0.6 update WiFi won't connect to other network // connection time increased

If nobody fixed this, there is no reason for a stupid stale bot closing this.

handmade0octopus

comment created time in 5 days

issue commentespressif/arduino-esp32

HttpClient crashes after HTTP request

If nobody solved it, there is no reason for a stupid stale bot just closes this.

@ppescher @me-no-dev can you have a look?

KenthJ

comment created time in 5 days

issue closedborgbackup/borg

Feature request: allow fast renaming (for rotating snapshots)

When renaming an archive it takes a few seconds as it seems that borg does some extra things than just changing the name (compacting etc.).

When using a set of rotating snapshots, for example:

create save, delete save10, save9 -> save10, save8 -> save9, ..., save1 -> save2, save -> save1

where -> means renaming, each of the renaming operations does more than renaming and takes quite a lot of time.

Would it be possible to add a --fast option to rename in which onle the name of the snapshot is changed ?

Thank you, best, Carlos PS I know I could purge but I have different sets of rotating snapshosts and there is no way purging allows me to keep the 10 last snapshots of each rotating set.

closed time in 5 days

carlosaguilarmelchor

issue commentborgbackup/borg

Feature request: allow fast renaming (for rotating snapshots)

borg 1.2 will have a separate compactsubcommand, so users can choose when to run this and it won't be run automatically at the end of any repo-writing command. but even with that, each borg command will have some startup overhead for loading repo and chunks index, doing self tests, etc.

for borg 1.1.x you will have to use prune and you must use its --prefix option to work with different backup sets inside one repo. there are also some other options like --keep-lastuseful for your case.

i guess i won't invest time in optimizing borg 1.1.x for fast renames as your use case can be better solved with prune and borg 1.2 / master branch already has the compact_segments tuning.

carlosaguilarmelchor

comment created time in 5 days

issue closedborgbackup/borg

Original size of All archives

<!-- Thank you for reporting an issue.

IMPORTANT - before creating a new issue please look around:

  • Borgbackup documentation: http://borgbackup.readthedocs.io/en/stable/index.html
  • FAQ: https://borgbackup.readthedocs.io/en/stable/faq.html and
  • open issues in Github tracker: https://github.com/borgbackup/borg/issues

If you cannot find a similar problem, then create a new issue.

Please fill in as much of the template as possible. -->

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

Yes

Is this a BUG / ISSUE report or a QUESTION?

QUESTION or maybe BUG/ISSUE/FEATURE

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

Your borg version (borg -V).

borg 1.1.16

Operating system (distribution) and version.

CentOS Linux release 7.9.2009 (Core)

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

borg info /path/to/archive::archivename

Describe the problem you're observing.

Hello. Why is the original size ("Original size" column) in the row describing all archives not equal to the sum of all archives added to the repository? Why does it show a different size that exceeds the sum of the original sizes of all archives? What does this size show? Thank you.

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

Yes

------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:                2.27 TB            467.83 GB             12.09 GB
All archives:               16.74 TB              3.16 TB            393.70 GB

Sum of all my archives is 2.27*5=11,35 TB

closed time in 5 days

izyk

issue commentborgbackup/borg

Original size of All archives

https://github.com/borgbackup/borg/discussions/5935 moved to there, closing here.

izyk

comment created time in 5 days

issue commentborgbackup/borg

ubuntu 21.04, ubuntu 21 and ubuntu 20.10 crashing

PermissionError: [Errno 13] Permission denied: '/media/backup/borg/data/0/871'

You need to fix permissions there, so that the user you use can access (rwx) that data.

GameTec-live

comment created time in 5 days

issue commentborgbackup/borg

ubuntu 21.04, ubuntu 21 and ubuntu 20.10 crashing

Typo: BORG_RHS instead of (correct) BORG_RSH - guess this is why it does not use your key.

GameTec-live

comment created time in 5 days

push eventborgbackup/borg

TW

commit sha 1e7c1414b030b3dd09c7daa451a2e078328ce4fc

Merge pull request #5902 from ThomasWaldmann/pull-chroot-problematic-1.1 docs: pull mode: add some warnings, fixes #5827

view details

TW

commit sha 96af6dd144b852648c0141db1114aeb704d32d45

Merge pull request #5911 from KN4CK3R/forwardport-5902 Forwardport pull request #5902

view details

push time in 5 days

issue closedborgbackup/borg

Pull mode documentation: Security: Client is able to run code on server

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

Yes

Is this a BUG / ISSUE report or a QUESTION?

Issue

Your borg version (borg -V).

1.1.16 (current documentation)


The pull backup documentation suggests to set up a chroot to back up remote servers. There is already a security warning that a compromised backup server will be able to "cause unlimited damage to the client".

However, this security issue goes both ways: A compromised client is likely to be able to run arbitrary code as root on the backup server. For example, a malicious client can replace its own shell binary. This is then run as root on the backup machine in the chroot context. Escaping the chroot is easy, e.g. the client is able to load malicious kernel modules on the backup host via insmod, or use one of the bind-mounted file systems (/dev /proc /sys) to escape the chroot, e.g. by manipulating /dev/mem.

The warning should be expanded that the compromise can work both ways. Ideally, the chroot solution should be replaced by something more secure. According to the pull backup documentation, the chroot is just performed so that borg will be able to read /etc/passwd and /etc/group. borg could introduce parameters to specify the path to these files so that chrooting will not be needed.

Further, the FAQ How can I protect against a hacked backup client? suggests that the pull mode documentation "protect[s] against" "the attacker could then use borg on C to delete all backups residing on S". For the reasons outlined above, the chroot solution does not prevent that.

closed time in 5 days

pcworld

PR merged borgbackup/borg

Forwardport pull request #5902
+16 -1

4 comments

1 changed file

KN4CK3R

pr closed time in 5 days