From tw at waldmann-edv.de  Sun Jan 21 08:33:16 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Sun, 21 Jan 2024 14:33:16 +0100
Subject: [Borgbackup] borgbackup 1.4.0b1 released!
Message-ID: <55b364b7-39f7-4373-a2e8-4bced35e890a@waldmann-edv.de>

Just released #borgbackup 1.4.0b1 beta version!

This is important for pre-release beta testing, but should not be used 
for production - please help testing!

https://github.com/borgbackup/borg/releases/tag/1.4.0b1


-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393

From bjo at schafweide.org  Mon Jan 22 02:58:36 2024
From: bjo at schafweide.org (Bjoern Franke)
Date: Mon, 22 Jan 2024 08:58:36 +0100
Subject: [Borgbackup] Schroedingers Repo?
Message-ID: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>

Hi,

yesterday I tried to init a repo on a Hetzner Storagebox and got a weird 
issue (all existing repos there work fine):

/usr/bin/borg init -e  none 
ssh://u123456 at u123456.your-storagebox.de:23/./bla
A repository already exists at 
ssh://u123456 at u123456.your-storagebox.de:23/./bla.

/usr/bin/borg list ssh://u123456 at u123456.your-storagebox.de:23/./bla
Repository ssh://u123456 at u123456.your-storagebox.de:23/./bla does not exist.

There is no directory "bla". I would assume there's something wrong on 
Hetzner's side?

Regards
Bjoern

From devzero at web.de  Mon Jan 22 03:44:57 2024
From: devzero at web.de (Roland privat)
Date: Mon, 22 Jan 2024 09:44:57 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
Message-ID: <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>

what does 

ssh -o port=23 u123456 at u123456.your-storagebox.de:23 ls -la 

show ?

Von meinem iPhone gesendet

> Am 22.01.2024 um 09:05 schrieb Bjoern Franke via Borgbackup <borgbackup at python.org>:
> 
> ?Hi,
> 
> yesterday I tried to init a repo on a Hetzner Storagebox and got a weird issue (all existing repos there work fine):
> 
> /usr/bin/borg init -e  none ssh://u123456 at u123456.your-storagebox.de:23/./bla
> A repository already exists at ssh://u123456 at u123456.your-storagebox.de:23/./bla.
> 
> /usr/bin/borg list ssh://u123456 at u123456.your-storagebox.de:23/./bla
> Repository ssh://u123456 at u123456.your-storagebox.de:23/./bla does not exist.
> 
> There is no directory "bla". I would assume there's something wrong on Hetzner's side?
> 
> Regards
> Bjoern
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup


From bjo at schafweide.org  Mon Jan 22 04:00:17 2024
From: bjo at schafweide.org (Bjoern Franke)
Date: Mon, 22 Jan 2024 10:00:17 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
 <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>
Message-ID: <8fdc1f5b-f665-4dea-8694-d32c577a47a6@schafweide.org>

Hi,

> what does
> 
> ssh -o port=23 u123456 at u123456.your-storagebox.de:23 ls -la
> 
> show ?
> 
>

as already mentioned, it does not exist:

ls: bla: No such file or directory



From bjo at schafweide.org  Mon Jan 22 04:11:03 2024
From: bjo at schafweide.org (Bjoern Franke)
Date: Mon, 22 Jan 2024 10:11:03 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <8fdc1f5b-f665-4dea-8694-d32c577a47a6@schafweide.org>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
 <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>
 <8fdc1f5b-f665-4dea-8694-d32c577a47a6@schafweide.org>
Message-ID: <70192a5c-897d-4f58-9646-3fd9928ec00f@schafweide.org>


> 
> as already mentioned, it does not exist:
> 
> ls: bla: No such file or directory

As I used the dir as a parameter for "ls -la", here now without it:


ssh -o port=23 u123456 at u123456.your-storagebox.de "ls -la"
total 267
drwxr-xr-x   8 u123456 u123456  9 Jan 21 20:54 .
dr-x--x--x  11 root     wheel    11 Dec 22 12:28 ..
drwxr-xr-x   2 u123456 u123456  3 Dec  9 12:14 .ssh
-rw-r--r--   1 u123456 u123456 73 May 15  2021 README
drwxr-xr-x   3 u123456 u123456  3 Dec  7 21:58 cloud
drwxr-xr-x   3 u123456 u123456  9 Jan 22 01:34 home
drwxr-xr-x   3 u123456 u123456  9 Jan 22 01:34 mail
drwxr-xr-x   3 u123456 u123456  8 Jan 22 00:57 pod
drwxr-xr-x   3 u123456 u123456  9 Jan 21 23:01 wa2






From tw at waldmann-edv.de  Mon Jan 22 09:30:59 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Mon, 22 Jan 2024 15:30:59 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
Message-ID: <42f84607-3016-4783-9bd8-b0c9265f5adb@waldmann-edv.de>

> yesterday I tried to init a repo on a Hetzner Storagebox and got a weird 
> issue (all existing repos there work fine):
> 
> /usr/bin/borg init -e? none 
> ssh://u123456 at u123456.your-storagebox.de:23/./bla
> A repository already exists at 
> ssh://u123456 at u123456.your-storagebox.de:23/./bla.
> 
> /usr/bin/borg list ssh://u123456 at u123456.your-storagebox.de:23/./bla
> Repository ssh://u123456 at u123456.your-storagebox.de:23/./bla does not 
> exist.

That's strange. Can you give the local and remote borg version, please?


-- 
GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393

From bjo at schafweide.org  Mon Jan 22 09:41:31 2024
From: bjo at schafweide.org (Bjoern Franke)
Date: Mon, 22 Jan 2024 15:41:31 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <42f84607-3016-4783-9bd8-b0c9265f5adb@waldmann-edv.de>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
 <42f84607-3016-4783-9bd8-b0c9265f5adb@waldmann-edv.de>
Message-ID: <5866014e-9ae5-4424-8c20-c6d357442ff1@schafweide.org>

Hi,

> 
> That's strange. Can you give the local and remote borg version, please?
> 
> 

local 1.2.7, remote 1.2.4

Regards
Bjoern

From tw at waldmann-edv.de  Mon Jan 22 11:46:01 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Mon, 22 Jan 2024 17:46:01 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <70192a5c-897d-4f58-9646-3fd9928ec00f@schafweide.org>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
 <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>
 <8fdc1f5b-f665-4dea-8694-d32c577a47a6@schafweide.org>
 <70192a5c-897d-4f58-9646-3fd9928ec00f@schafweide.org>
Message-ID: <cd857b08-4e82-45a3-bd1d-41f2ee282392@waldmann-edv.de>

borg does not let you create a borg repository inside another borg 
repository.

It checks that at "borg init" time by looking for the borg README in all 
parent directories. If it finds one, it says "Repository already exists 
at ...".

It looks like you have such a README there (but there is no data/ 
directory and also no other files typically found in a borg repo on that 
directory level, so guess just just forgot to remove that README file 
when cleaning up).


On 22.01.24 10:11, Bjoern Franke via Borgbackup wrote:
> 
>>
>> as already mentioned, it does not exist:
>>
>> ls: bla: No such file or directory
> 
> As I used the dir as a parameter for "ls -la", here now without it:
> 
> 
> ssh -o port=23 u123456 at u123456.your-storagebox.de "ls -la"
> total 267
> drwxr-xr-x?? 8 u123456 u123456? 9 Jan 21 20:54 .
> dr-x--x--x? 11 root???? wheel??? 11 Dec 22 12:28 ..
> drwxr-xr-x?? 2 u123456 u123456? 3 Dec? 9 12:14 .ssh
> -rw-r--r--?? 1 u123456 u123456 73 May 15? 2021 README
> drwxr-xr-x?? 3 u123456 u123456? 3 Dec? 7 21:58 cloud
> drwxr-xr-x?? 3 u123456 u123456? 9 Jan 22 01:34 home
> drwxr-xr-x?? 3 u123456 u123456? 9 Jan 22 01:34 mail
> drwxr-xr-x?? 3 u123456 u123456? 8 Jan 22 00:57 pod
> drwxr-xr-x?? 3 u123456 u123456? 9 Jan 21 23:01 wa2


-- 
Waldmann EDV Systeme/Service GbR
Gerhard Waldmann, Thomas Waldmann
Pleidelsheimer Str. 25
74321 Bietigheim-Bissingen

Weitere Infos siehe: http://waldmann-edv.de/

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From devzero at web.de  Mon Jan 22 13:16:18 2024
From: devzero at web.de (Roland)
Date: Mon, 22 Jan 2024 19:16:18 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <cd857b08-4e82-45a3-bd1d-41f2ee282392@waldmann-edv.de>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
 <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>
 <8fdc1f5b-f665-4dea-8694-d32c577a47a6@schafweide.org>
 <70192a5c-897d-4f58-9646-3fd9928ec00f@schafweide.org>
 <cd857b08-4e82-45a3-bd1d-41f2ee282392@waldmann-edv.de>
Message-ID: <64211f2a-68d1-4526-a75b-155f008d25fc@web.de>

hello ,

if even the original author of borg thought this is "strange" on a first
view,? wouldn't some additional and more
explanatory readme/marker file like "THIS_IS_A_BORGEPO_DIR"? make sense ?

at least some more informational message could be helpful to better see,
why borg thinks some dir is a repo.

README could have been any READMY (that's pretty ordinary filename),
maybe even README.borg would be
more self explanatory.

regards
roland


Am 22.01.24 um 17:46 schrieb Thomas Waldmann:

> borg does not let you create a borg repository inside another borg
> repository.
>
> It checks that at "borg init" time by looking for the borg README in
> all parent directories. If it finds one, it says "Repository already
> exists at ...".
>
> It looks like you have such a README there (but there is no data/
> directory and also no other files typically found in a borg repo on
> that directory level, so guess just just forgot to remove that README
> file when cleaning up).
>
>
> On 22.01.24 10:11, Bjoern Franke via Borgbackup wrote:
>>
>>>
>>> as already mentioned, it does not exist:
>>>
>>> ls: bla: No such file or directory
>>
>> As I used the dir as a parameter for "ls -la", here now without it:
>>
>>
>> ssh -o port=23 u123456 at u123456.your-storagebox.de "ls -la"
>> total 267
>> drwxr-xr-x?? 8 u123456 u123456? 9 Jan 21 20:54 .
>> dr-x--x--x? 11 root???? wheel??? 11 Dec 22 12:28 ..
>> drwxr-xr-x?? 2 u123456 u123456? 3 Dec? 9 12:14 .ssh
>> -rw-r--r--?? 1 u123456 u123456 73 May 15? 2021 README
>> drwxr-xr-x?? 3 u123456 u123456? 3 Dec? 7 21:58 cloud
>> drwxr-xr-x?? 3 u123456 u123456? 9 Jan 22 01:34 home
>> drwxr-xr-x?? 3 u123456 u123456? 9 Jan 22 01:34 mail
>> drwxr-xr-x?? 3 u123456 u123456? 8 Jan 22 00:57 pod
>> drwxr-xr-x?? 3 u123456 u123456? 9 Jan 21 23:01 wa2
>
>

From devzero at web.de  Mon Jan 22 13:33:16 2024
From: devzero at web.de (Roland privat)
Date: Mon, 22 Jan 2024 19:33:16 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <25BCEEC9-6B76-40D6-BEFA-EACB09A0E2A7@XS4All.nl>
References: <25BCEEC9-6B76-40D6-BEFA-EACB09A0E2A7@XS4All.nl>
Message-ID: <864340AD-D31E-49A7-AC84-8C30B31CB37E@web.de>

yes, it?s not empty and the contents matter regarding detection.

anyhow - that file alone could be any readme and nobody  expects that some README lying around turns an ordinary dir into a borg repo.

roland



Von meinem iPhone gesendet

> Am 22.01.2024 um 19:30 schrieb Gerrit A. Smit <GerritASmit at xs4all.nl>:
> 
> ?
> 
>> Op 22 jan. 2024, om 19:16 heeft Roland via Borgbackup <borgbackup at python.org> het volgende geschreven:
>> 
>> hello ,
>> 
>> if even the original author of borg thought this is "strange" on a first
>> view,  wouldn't some additional and more
>> explanatory readme/marker file like "THIS_IS_A_BORGEPO_DIR"  make sense ?
>> 
>> at least some more informational message could be helpful to better see,
>> why borg thinks some dir is a repo.
>> 
>> README could have been any READMY (that's pretty ordinary filename),
>> maybe even README.borg would be
>> more self explanatory.
> 
> It's not an empty file.
> What's in it?
> 
> ? 
> Gerrit A. Smit
> Malden
> GerritASmit at XS4All.nl
> 


From devzero at web.de  Mon Jan 22 13:56:08 2024
From: devzero at web.de (Roland privat)
Date: Mon, 22 Jan 2024 19:56:08 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <C3AD84F9-9C57-4441-8DE8-F4D831337B69@XS4All.nl>
References: <C3AD84F9-9C57-4441-8DE8-F4D831337B69@XS4All.nl>
Message-ID: <B1D0E97D-3FB3-41FA-ADCB-FE51827EA693@web.de>

yes, but they are also expected to contain documentation / information for the reader and not expected to contain metadata to be read by  tools.


Von meinem iPhone gesendet

> Am 22.01.2024 um 19:37 schrieb Gerrit A. Smit <GerritASmit at xs4all.nl>:
> 
> ?
> 
>> Op 22 jan. 2024, om 19:33 heeft Roland privat <devzero at web.de> het volgende geschreven:
>> 
>> yes, it?s not empty and the contents matter regarding detection.
>> 
>> anyhow - that file alone could be any readme and nobody  expects that some README lying around turns an ordinary dir into a borg repo.
>> 
>> 
> 
> README-files are expected to be read.
> 
> ? 
> Gerrit A. Smit
> Malden
> GerritASmit at XS4All.nl
> 


From bjo at schafweide.org  Mon Jan 22 14:24:19 2024
From: bjo at schafweide.org (Bjoern Franke)
Date: Mon, 22 Jan 2024 20:24:19 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <64211f2a-68d1-4526-a75b-155f008d25fc@web.de>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
 <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>
 <8fdc1f5b-f665-4dea-8694-d32c577a47a6@schafweide.org>
 <70192a5c-897d-4f58-9646-3fd9928ec00f@schafweide.org>
 <cd857b08-4e82-45a3-bd1d-41f2ee282392@waldmann-edv.de>
 <64211f2a-68d1-4526-a75b-155f008d25fc@web.de>
Message-ID: <9e79f68d-9497-425f-b082-2672870768a2@schafweide.org>

Hi,


> if even the original author of borg thought this is "strange" on a first
> view,? wouldn't some additional and more
> explanatory readme/marker file like "THIS_IS_A_BORGEPO_DIR"? make sense ?
> 
> at least some more informational message could be helpful to better see,
> why borg thinks some dir is a repo.

Yes, if I would have remembered that the README is considered as a repo 
marker I would have removed it.

And somehow the error message is misleading. As the top level directory 
is considered als borg repo, it should be

A repository already exists at
ssh://u123456 at u123456.your-storagebox.de:23/

instead of

A repository already exists at
ssh://u123456 at u123456.your-storagebox.de:23/./bla.

as ./bla is nonexistent.

Regards
Bjoern





From tw at waldmann-edv.de  Tue Jan 23 10:51:02 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Tue, 23 Jan 2024 16:51:02 +0100
Subject: [Borgbackup] Schroedingers Repo?
In-Reply-To: <9e79f68d-9497-425f-b082-2672870768a2@schafweide.org>
References: <1b4da63d-07ed-4083-9f9c-35e002b4922e@schafweide.org>
 <7346CC30-AD8C-43B6-91AB-9FF3C8128400@web.de>
 <8fdc1f5b-f665-4dea-8694-d32c577a47a6@schafweide.org>
 <70192a5c-897d-4f58-9646-3fd9928ec00f@schafweide.org>
 <cd857b08-4e82-45a3-bd1d-41f2ee282392@waldmann-edv.de>
 <64211f2a-68d1-4526-a75b-155f008d25fc@web.de>
 <9e79f68d-9497-425f-b082-2672870768a2@schafweide.org>
Message-ID: <e129611d-a64d-45fb-aa2f-6f9c7b1789f0@waldmann-edv.de>

> And somehow the error message is misleading. As the top level directory 
> is considered als borg repo, it should be
> 
> A repository already exists at
> ssh://u123456 at u123456.your-storagebox.de:23/
> 
> instead of
> 
> A repository already exists at
> ssh://u123456 at u123456.your-storagebox.de:23/./bla.
> 
> as ./bla is nonexistent.

I had a look at the code:

The exception raised on the server side ("borg serve") actually contains 
the correct, but (from its perspective) *local* path.

The RPC layer on the client side translates that exception and always 
uses the "processed" location (as the user gave it, but after expansion 
of placeholders).

Considering what the client knows and what the server knows, guess there 
is no easy way to improve that.

From lazyvirus at gmx.com  Thu Jan 25 16:48:17 2024
From: lazyvirus at gmx.com (Bzzzz)
Date: Thu, 25 Jan 2024 22:48:17 +0100
Subject: [Borgbackup] Regular backup strange behavior (stuck)
Message-ID: <20240125224817.5554c0a2@msi.defcon1.lan>

debian : bookworm
borg   : 1.2.7 (from pip)
repo   : mounted on the client with nfs
	 (readable from another console,
	  so not a network PB)
========================================

Hi list,

One machine normally takes something like 30'~35' to backup, however
today borg is up for largely more than 1 hour !?
start time : 21:01:29
this time  : 22:45:09

The console where my script was launched shows the usual list of
modified files, no recap so it is assumed to be still running, there
is no error message at all and the last repo file shows one created file
with the last access 2' after backup was started and that is all :
$ sudo stat /NFS/BORG/data/3/3992
  File: /NFS/BORG/data/3/3992
  Size: 147182858 	Blocks: 287480     IO Block: 131072 regular
file Device: 0,87	Inode: 112984077   Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-01-25 21:02:26.104944402 +0100
Modify: 2024-01-25 21:03:07.375370789 +0100
Change: 2024-01-25 21:03:07.375370789 +0100
 Birth: -

I already tried to kill borg and relaunch it but with the same result,
it stays stuck on the last (?) modified file and nothing else occurs.

What could be wrong ?

Jean-Yves

From lazyvirus at gmx.com  Thu Jan 25 23:20:15 2024
From: lazyvirus at gmx.com (Bzzzz)
Date: Fri, 26 Jan 2024 05:20:15 +0100
Subject: [Borgbackup] Regular backup strange behavior (stuck)
In-Reply-To: <20240125224817.5554c0a2@msi.defcon1.lan>
References: <20240125224817.5554c0a2@msi.defcon1.lan>
Message-ID: <20240126052015.09a91073@msi.defcon1.lan>

On Thu, 25 Jan 2024 22:48:17 +0100
Bzzzz via Borgbackup <borgbackup at python.org> wrote:

I made a forced fsck of the repo disk that did not show any problem
and followed by a borg check with rc=0.

I still can't see what could be the cause of borg being stuck.

JY

> debian : bookworm
> borg   : 1.2.7 (from pip)
> repo   : mounted on the client with nfs
> 	 (readable from another console,
> 	  so not a network PB)
> ========================================
>
> Hi list,
>
> One machine normally takes something like 30'~35' to backup, however
> today borg is up for largely more than 1 hour !?
> start time : 21:01:29
> this time  : 22:45:09
>
> The console where my script was launched shows the usual list of
> modified files, no recap so it is assumed to be still running, there
> is no error message at all and the last repo file shows one created
> file with the last access 2' after backup was started and that is all
> : $ sudo stat /NFS/BORG/data/3/3992
>   File: /NFS/BORG/data/3/3992
>   Size: 147182858 	Blocks: 287480     IO Block: 131072 regular
> file Device: 0,87	Inode: 112984077   Links: 1
> Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/
> root) Access: 2024-01-25 21:02:26.104944402 +0100
> Modify: 2024-01-25 21:03:07.375370789 +0100
> Change: 2024-01-25 21:03:07.375370789 +0100
>  Birth: -
>
> I already tried to kill borg and relaunch it but with the same result,
> it stays stuck on the last (?) modified file and nothing else occurs.
>
> What could be wrong ?
>
> Jean-Yves
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup


From peter at crazymonkeys.de  Fri Jan 26 07:31:12 2024
From: peter at crazymonkeys.de (Peter Albrecht)
Date: Fri, 26 Jan 2024 13:31:12 +0100
Subject: [Borgbackup] Regular backup strange behavior (stuck)
In-Reply-To: <20240126052015.09a91073@msi.defcon1.lan>
References: <20240125224817.5554c0a2@msi.defcon1.lan>
 <20240126052015.09a91073@msi.defcon1.lan>
Message-ID: <f98eb7e8-19e1-48c0-82b1-af7517bdd6b0@crazymonkeys.de>

Hi JY,

how much data do you backup?

I recently added a virtual machine (50 GB) to my backup. Although most of the 
vm's virtual disk does not change, borg now always has to crunch all those 50 GB 
to find changes. This takes way longer than in times without this virtual disk.

Maybe some metadata of your files changed, so borg has to check a lot of data now.


A sponatnous idea:
You can run "borg create" via "strace":

   # strace borg create ...

See https://www.baeldung.com/linux/strace-command for more information.

Regards,
	Peter



On 26.01.24 05:20, Bzzzz via Borgbackup wrote:
> On Thu, 25 Jan 2024 22:48:17 +0100
> Bzzzz via Borgbackup <borgbackup at python.org> wrote:
> 
> I made a forced fsck of the repo disk that did not show any problem
> and followed by a borg check with rc=0.
> 
> I still can't see what could be the cause of borg being stuck.
> 
> JY
> 
>> debian : bookworm
>> borg   : 1.2.7 (from pip)
>> repo   : mounted on the client with nfs
>> 	 (readable from another console,
>> 	  so not a network PB)
>> ========================================
>>
>> Hi list,
>>
>> One machine normally takes something like 30'~35' to backup, however
>> today borg is up for largely more than 1 hour !?
>> start time : 21:01:29
>> this time  : 22:45:09
>>
>> The console where my script was launched shows the usual list of
>> modified files, no recap so it is assumed to be still running, there
>> is no error message at all and the last repo file shows one created
>> file with the last access 2' after backup was started and that is all
>> : $ sudo stat /NFS/BORG/data/3/3992
>>    File: /NFS/BORG/data/3/3992
>>    Size: 147182858 	Blocks: 287480     IO Block: 131072 regular
>> file Device: 0,87	Inode: 112984077   Links: 1
>> Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/
>> root) Access: 2024-01-25 21:02:26.104944402 +0100
>> Modify: 2024-01-25 21:03:07.375370789 +0100
>> Change: 2024-01-25 21:03:07.375370789 +0100
>>   Birth: -
>>
>> I already tried to kill borg and relaunch it but with the same result,
>> it stays stuck on the last (?) modified file and nothing else occurs.
>>
>> What could be wrong ?
>>
>> Jean-Yves
>> _______________________________________________
>> Borgbackup mailing list
>> Borgbackup at python.org
>> https://mail.python.org/mailman/listinfo/borgbackup
> 
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup

From lazyvirus at gmx.com  Fri Jan 26 07:46:30 2024
From: lazyvirus at gmx.com (Bzzzz)
Date: Fri, 26 Jan 2024 13:46:30 +0100
Subject: [Borgbackup] Regular backup strange behavior (stuck)
In-Reply-To: <f98eb7e8-19e1-48c0-82b1-af7517bdd6b0@crazymonkeys.de>
References: <20240125224817.5554c0a2@msi.defcon1.lan>
 <20240126052015.09a91073@msi.defcon1.lan>
 <f98eb7e8-19e1-48c0-82b1-af7517bdd6b0@crazymonkeys.de>
Message-ID: <20240126134630.55e9c289@msi.defcon1.lan>

On Fri, 26 Jan 2024 13:31:12 +0100
Peter Albrecht <peter at crazymonkeys.de> wrote:

> Hi JY,

Hi Peter,

> how much data do you backup?

Not much, the machine in question only has ~550 GB.

> I recently added a virtual machine (50 GB) to my backup. Although
> most of the vm's virtual disk does not change, borg now always has to
> crunch all those 50 GB to find changes. This takes way longer than in
> times without this virtual disk.

That I know, I reduced the slice size especially to avoid that, but
images have not been touched since the last correct backup, so it
can't be that (and anyway the biggest being 50 GB, it wouldn't take
that much time, any modif adds around 10', not more).

> Maybe some metadata of your files changed, so borg has to check a lot
> of data now.

Again not that I know of and it can't be that, otherwise I would see
these files printing on the console with a leading 'M', but the list
has stopped, iotop doesn't show any borg activity and the HDD isn't
more active than when the machine's idle :/

> A sponatnous idea:
> You can run "borg create" via "strace":
>
>    # strace borg create ...

Ok, I'll launching it in ~15 minutes - I have some errand to run, so
I'll see if it spits something weird when coming back.

Regards,
Jean-Yves


> On 26.01.24 05:20, Bzzzz via Borgbackup wrote:
> > On Thu, 25 Jan 2024 22:48:17 +0100
> > Bzzzz via Borgbackup <borgbackup at python.org> wrote:
> >
> > I made a forced fsck of the repo disk that did not show any problem
> > and followed by a borg check with rc=0.
> >
> > I still can't see what could be the cause of borg being stuck.
> >
> > JY
> >
> >> debian : bookworm
> >> borg   : 1.2.7 (from pip)
> >> repo   : mounted on the client with nfs
> >> 	 (readable from another console,
> >> 	  so not a network PB)
> >> ========================================
> >>
> >> Hi list,
> >>
> >> One machine normally takes something like 30'~35' to backup,
> >> however today borg is up for largely more than 1 hour !?
> >> start time : 21:01:29
> >> this time  : 22:45:09
> >>
> >> The console where my script was launched shows the usual list of
> >> modified files, no recap so it is assumed to be still running,
> >> there is no error message at all and the last repo file shows one
> >> created file with the last access 2' after backup was started and
> >> that is all : $ sudo stat /NFS/BORG/data/3/3992
> >>    File: /NFS/BORG/data/3/3992
> >>    Size: 147182858 	Blocks: 287480     IO Block: 131072
> >> regular file Device: 0,87	Inode: 112984077   Links: 1
> >> Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/
> >> root) Access: 2024-01-25 21:02:26.104944402 +0100
> >> Modify: 2024-01-25 21:03:07.375370789 +0100
> >> Change: 2024-01-25 21:03:07.375370789 +0100
> >>   Birth: -
> >>
> >> I already tried to kill borg and relaunch it but with the same
> >> result, it stays stuck on the last (?) modified file and nothing
> >> else occurs.
> >>
> >> What could be wrong ?
> >>
> >> Jean-Yves
> >> _______________________________________________
> >> Borgbackup mailing list
> >> Borgbackup at python.org
> >> https://mail.python.org/mailman/listinfo/borgbackup
> >
> > _______________________________________________
> > Borgbackup mailing list
> > Borgbackup at python.org
> > https://mail.python.org/mailman/listinfo/borgbackup
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup


From lazyvirus at gmx.com  Fri Jan 26 08:55:30 2024
From: lazyvirus at gmx.com (Bzzzz)
Date: Fri, 26 Jan 2024 14:55:30 +0100
Subject: [Borgbackup] Regular backup strange behavior (stuck) - [SOLVED
 but]
In-Reply-To: <f98eb7e8-19e1-48c0-82b1-af7517bdd6b0@crazymonkeys.de>
References: <20240125224817.5554c0a2@msi.defcon1.lan>
 <20240126052015.09a91073@msi.defcon1.lan>
 <f98eb7e8-19e1-48c0-82b1-af7517bdd6b0@crazymonkeys.de>
Message-ID: <20240126145530.758fa753@msi.defcon1.lan>

On Fri, 26 Jan 2024 13:31:12 +0100
Peter Albrecht <peter at crazymonkeys.de> wrote:

Finally, the strace ended w/ rc=1 (usual, generally a log file being
written while borg accessing it) after ~47' and listing all backups
shows this last one clearly.

I still don't know what happened as I do not see any daemon/program
touching a bunch of files. May be glitches in client cache files (but
normally, I would have had an error message ?), duno.

This is the first time I have such a strange borg behavior.

Thanks anyway, if it happens again I'll wait a looong time before
starting to fret.

Regards,
Jean-Yves

> Hi JY,
>
> how much data do you backup?
>
> I recently added a virtual machine (50 GB) to my backup. Although
> most of the vm's virtual disk does not change, borg now always has to
> crunch all those 50 GB to find changes. This takes way longer than in
> times without this virtual disk.
>
> Maybe some metadata of your files changed, so borg has to check a lot
> of data now.
>
>
> A sponatnous idea:
> You can run "borg create" via "strace":
>
>    # strace borg create ...
>
> See https://www.baeldung.com/linux/strace-command for more
> information.
>
> Regards,
> 	Peter
>
>
>
> On 26.01.24 05:20, Bzzzz via Borgbackup wrote:
> > On Thu, 25 Jan 2024 22:48:17 +0100
> > Bzzzz via Borgbackup <borgbackup at python.org> wrote:
> >
> > I made a forced fsck of the repo disk that did not show any problem
> > and followed by a borg check with rc=0.
> >
> > I still can't see what could be the cause of borg being stuck.
> >
> > JY
> >
> >> debian : bookworm
> >> borg   : 1.2.7 (from pip)
> >> repo   : mounted on the client with nfs
> >> 	 (readable from another console,
> >> 	  so not a network PB)
> >> ========================================
> >>
> >> Hi list,
> >>
> >> One machine normally takes something like 30'~35' to backup,
> >> however today borg is up for largely more than 1 hour !?
> >> start time : 21:01:29
> >> this time  : 22:45:09
> >>
> >> The console where my script was launched shows the usual list of
> >> modified files, no recap so it is assumed to be still running,
> >> there is no error message at all and the last repo file shows one
> >> created file with the last access 2' after backup was started and
> >> that is all : $ sudo stat /NFS/BORG/data/3/3992
> >>    File: /NFS/BORG/data/3/3992
> >>    Size: 147182858 	Blocks: 287480     IO Block: 131072
> >> regular file Device: 0,87	Inode: 112984077   Links: 1
> >> Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/
> >> root) Access: 2024-01-25 21:02:26.104944402 +0100
> >> Modify: 2024-01-25 21:03:07.375370789 +0100
> >> Change: 2024-01-25 21:03:07.375370789 +0100
> >>   Birth: -
> >>
> >> I already tried to kill borg and relaunch it but with the same
> >> result, it stays stuck on the last (?) modified file and nothing
> >> else occurs.
> >>
> >> What could be wrong ?
> >>
> >> Jean-Yves
> >> _______________________________________________
> >> Borgbackup mailing list
> >> Borgbackup at python.org
> >> https://mail.python.org/mailman/listinfo/borgbackup
> >
> > _______________________________________________
> > Borgbackup mailing list
> > Borgbackup at python.org
> > https://mail.python.org/mailman/listinfo/borgbackup
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup


From tw at waldmann-edv.de  Wed Feb 21 01:20:29 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Wed, 21 Feb 2024 07:20:29 +0100
Subject: [Borgbackup] borg 2.0.0b8 released!
Message-ID: <df77612e-3ae5-42d5-a59a-49a53d184b7a@waldmann-edv.de>

Just released a new #borgbackup 2 beta:

https://github.com/borgbackup/borg/releases/tag/2.0.0b8

#linux #bsd #macos

From Nikolic97 at disroot.org  Wed Feb 21 12:37:24 2024
From: Nikolic97 at disroot.org (Nayla Nikolic)
Date: Wed, 21 Feb 2024 18:37:24 +0100
Subject: [Borgbackup] Raspberry "4 vs 5" for encrypted Borg backup / will
 the performance be significantly better with 5?
Message-ID: <378604c6-229a-4d26-bef5-91ccb1818a3a@disroot.org>

Hi

I use the current Ubuntu with encrypted borgbackup from the official 
repo on a RPI4. Borgbackup clients are various MacBooks which are 
connected to the borgbackup server (RPI4) via Ethernet cable. The RAID 
disks are connected to the Raspberry Pi 4 via USB.

I am thinking about upgrading to RPI5. Will the backup performance be 
significantly better? Or will the difference be rather small?

Does anyone have any experience?

I encrypt twice: once with LUKS and once in the borgbackup layer. That 
should be of some use with the faster CPU in the 5 series.

The USB interface in the 5 Series is also faster, or am I mistaken?

Best regards
Nayla

From borgbackup-list at thomas.freit.ag  Wed Feb 21 16:28:57 2024
From: borgbackup-list at thomas.freit.ag (borgbackup-list at thomas.freit.ag)
Date: Wed, 21 Feb 2024 22:28:57 +0100
Subject: [Borgbackup] Ignoring files
Message-ID: <a0f92f59-b14e-4cb4-9bba-04186b2829bb@thomas.freit.ag>

Hi,

I am running borg to backup several systems (mostly Linux), I try to exclude temporary or short living files. However occasionally those files are part of the logs and borg terminates with an 
non-zero returncode.

Example command:
borg create --info --show-rc --list --filter ACME --stats --patterns-from /dev/shm/borg-8d8e4e808be817cf/patterns --upload-ratelimit 0 --exclude-caches --exclude-nodump  --exclude re:'.*/temp' 
'ssh://<user>@<host>:<port>/<path>::{hostname}-{now}' /home /etc /root

Output (of a hourly run, impressive: under 5mins for about 2TB of data and about 860,000 files!):
Creating archive at "ssh://<user>@<host>:<port>/<path>::<host>-2024-02-20T08:17:01"
A /somepath/Maildir/new/23445334245.M239643453544462.host,S=96084,W=97546
A /someotherpath/Maildir/cur/645746746746.M75793935345433115.host,S=4870,W=4965:2,S
/yetanotherpath/Maildir/.INBOX.Operating.backup/dovecot-uidlist.lock: stat: [Errno 2] No such file or directory: 'dovecot-uidlist.lock'
/yetanotherpath/Maildir/.INBOX.Operating.backup/dovecot-uidlist.tmp: stat: [Errno 2] No such file or directory: 'dovecot-uidlist.tmp'
A /yetanotherpath/Maildir/new/353466456.M372671P2888743.host,S=3997,W=4089
A /yetanotherpath/Maildir/.Sent/cur/4636346363.M1835345817911.host,S=1417,W=1455:2,RS
A /yetanotherpath/Maildir/.Sent/cur/2452345235.M1210353488726.host,S=2479,W=2538:2,S
------------------------------------------------------------------------------
Repository: ssh://<user>@<host>:<port>/<path>
Archive name: host-2024-02-20T08:17:01
Archive fingerprint: aabbccddee...ff
Time (start): Tue, 2024-02-20 08:17:05
Time (end):   Tue, 2024-02-20 08:21:30
Duration: 4 minutes 25.46 seconds
Number of files: 859768
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                        Original size      Compressed size    Deduplicated size
This archive:                2.00 TB              1.98 TB              1.69 MB
All archives:              218.17 TB            215.89 TB              1.96 TB

                        Unique chunks         Total chunks
Chunk index:                 1615215            172898855
------------------------------------------------------------------------------
terminating with warning status, rc 1

Pattern file contains following lines (beside some others):
- re:.*\.lock$
- re:.*\.tmp$

Any chance to tell borg to really ignore those files, i.e. do not list them as error and quit with a zero exit code? I monitor every borg run and everytime it exits with a non-zero returncode, 
it gets escalated to me. I'd really like to ignore these errors on files, which I do not want to backup (which are on my ignore pattern list). Unforturnately using a filesystem with snapshot 
capabilities (and taking a snapshot to backup from a stable source) is not an option for most of the systems I backup.

Regards,
Thomas

From tw at waldmann-edv.de  Thu Feb 22 06:31:28 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Thu, 22 Feb 2024 12:31:28 +0100
Subject: [Borgbackup] Raspberry "4 vs 5" for encrypted Borg backup /
 will the performance be significantly better with 5?
In-Reply-To: <378604c6-229a-4d26-bef5-91ccb1818a3a@disroot.org>
References: <378604c6-229a-4d26-bef5-91ccb1818a3a@disroot.org>
Message-ID: <61da0f70-bea2-4e89-b284-01d0235f3f5a@waldmann-edv.de>

I can't comment much on RPi with borg as I don't use them with borg.
I didn't have a great experience concerning reliability, esp. not with 
the SDcard usually used for the OS.

If you didn't buy it yet, make sure you get a version with enough RAM 
for your current and future needs, as you can't upgrade the RAM.
There's a formula in the docs about borg's memory needs.

> I use the current Ubuntu with encrypted borgbackup from the official 
> repo on a RPI4.

In general, using the latest borg stable release is a good idea (because 
you get all the available bug fixes and other improvements).

See the borgbackup/community repo or the docs for useful links.

> Will the backup performance be significantly better?

That depends on where the actual bottleneck currently is and whether the 
hw upgrade makes a difference in respect to THAT.

If you run borg as client / server (== you use a "ssh://borg at raspi/..." 
repo):

The chunking, hashing, compression, encryption, authentication is done 
on the CLIENT.

SERVER:
- borg serve does mainly I/O (and crc32).
- But there might be also ssh and LUKS outside of borg in your case, 
doing crypto ops.


-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From tw at waldmann-edv.de  Thu Feb 22 06:42:30 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Thu, 22 Feb 2024 12:42:30 +0100
Subject: [Borgbackup] Ignoring files
In-Reply-To: <a0f92f59-b14e-4cb4-9bba-04186b2829bb@thomas.freit.ag>
References: <a0f92f59-b14e-4cb4-9bba-04186b2829bb@thomas.freit.ag>
Message-ID: <6a3e91b1-27d3-46c2-8d30-6e5385ceb775@waldmann-edv.de>

> Output (of a hourly run, impressive: under 5mins for about 2TB of data 
> and about 860,000 files!):

Speed is due to the files cache. :-)

> /yetanotherpath/Maildir/.INBOX.Operating.backup/dovecot-uidlist.tmp: 
> stat: [Errno 2] No such file or directory: 'dovecot-uidlist.tmp'
 > ...
> terminating with warning status, rc 1
> 
> Pattern file contains following lines (beside some others):
> - re:.*\.lock$
> - re:.*\.tmp$

Hmm, the regex patterns look correct. Strange.

Maybe file a bug and include a minimal(!) script that reproduces the 
problem. Also include the borg version.

> Unforturnately using a 
> filesystem with snapshot capabilities (and taking a snapshot to backup 
> from a stable source) is not an option for most of the systems I backup.

Pity. Because the main problem of course is that the inbox is locked for 
a reason (activity in the mail files) and you could end up backing up an 
inconsistent state of the files in the worst case.


-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From jdc at uwo.ca  Thu Feb 22 09:44:49 2024
From: jdc at uwo.ca (Dan Christensen)
Date: Thu, 22 Feb 2024 14:44:49 +0000
Subject: [Borgbackup] Ignoring files
In-Reply-To: <6a3e91b1-27d3-46c2-8d30-6e5385ceb775@waldmann-edv.de> (Thomas
 Waldmann's message of "Thu, 22 Feb 2024 12:42:30 +0100")
References: <a0f92f59-b14e-4cb4-9bba-04186b2829bb@thomas.freit.ag>
 <6a3e91b1-27d3-46c2-8d30-6e5385ceb775@waldmann-edv.de>
Message-ID: <878r3cd0db.fsf@uwo.ca>

On Feb 22, 2024, Thomas Waldmann <tw at waldmann-edv.de> wrote:

>> /yetanotherpath/Maildir/.INBOX.Operating.backup/dovecot-uidlist.tmp:
>> stat: [Errno 2] No such file or directory: 'dovecot-uidlist.tmp'
>> ...
>> terminating with warning status, rc 1
>> Pattern file contains following lines (beside some others):
>> - re:.*\.lock$
>> - re:.*\.tmp$
>
> Hmm, the regex patterns look correct. Strange.

Could it be due to other lines in the patterns file?  The order matters,
right?

It's also probably worth mentioning that borg uses rc 1 for files
changed and rc 2 for errors, so scripts can differentiate.

Also, IIRC, borg 2 (in beta), supports retrying changed files.

Dan

From donotspam at fastmail.fm  Sun Feb 25 17:39:04 2024
From: donotspam at fastmail.fm (Gareth Evans)
Date: Sun, 25 Feb 2024 22:39:04 +0000
Subject: [Borgbackup] Problems after borg client upgrade
Message-ID: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>

I use borg client 1.2.4 on Debian bookworm with 1.2.7 on a FreeBSD server, of which (the server) I am not in control.

Repos are encrypted using local keyfiles, and were created quite some time ago.

On the first day of the month, the last-day-of-last-month's repo is converted to that month's archive for the year.  I have a script which does:

borg delete redacted at redacted:$repo::m$lastmonth
borg rename redacted at redacted:$repo::d$yesterday m$lastmonth

$ borg --version
borg 1.2.4
$ sudo borg check redacted at redacted:etc
$

After upgrading the client version to 1.2.7 from bookworm-backports, problems are reported with the archives which have been renamed.

--
$ sudo borg check redacted at redacted:etc
Archive TAM authentication issue for archive m07: Data integrity error: Archive authentication did not verify
This archive will be *removed* from the manifest! It will be deleted.
Archive TAM authentication issue for archive m08: Data integrity error: Archive authentication did not verify
This archive will be *removed* from the manifest! It will be deleted.
Archive TAM authentication issue for archive m09: Data integrity error: Archive authentication did not verify
This archive will be *removed* from the manifest! It will be deleted.
Archive TAM authentication issue for archive m10: Data integrity error: Archive authentication did not verify
This archive will be *removed* from the manifest! It will be deleted.
Archive TAM authentication issue for archive m11: Data integrity error: Archive authentication did not verify
This archive will be *removed* from the manifest! It will be deleted.
Archive TAM authentication issue for archive m12: Data integrity error: Archive authentication did not verify
This archive will be *removed* from the manifest! It will be deleted.
Archive TAM authentication issue for archive m01: Data integrity error: Archive authentication did not verify
This archive will be *removed* from the manifest! It will be deleted.
162 orphaned objects found!
Archive consistency check complete, problems found.
--

Listing, for example, m01 produces

--
$ sudo borg list redacted at redacted:etc::m01
Data integrity error: Archive authentication did not verify
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5343, in main
    exit_code = archiver.run(args)
                ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5263, in run
    return set_ec(func(args))
                  ^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 189, in wrapper
    return method(self, args, repository=repository, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1385, in do_list
    return self._list_archive(args, repository, manifest, key)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1414, in _list_archive
    _list_inner(cache=None)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1402, in _list_inner
    archive = Archive(repository, key, manifest, args.location.archive, cache=cache,
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/borg/archive.py", line 488, in __init__
    self.load(info.id)
  File "/usr/lib/python3/dist-packages/borg/archive.py", line 501, in load
    self.metadata = self._load_meta(self.id)
                    ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/borg/archive.py", line 493, in _load_meta
    archive, self.tam_verified, _ = self.key.unpack_and_verify_archive(data, force_tam_not_required=True)
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/borg/crypto/key.py", line 329, in unpack_and_verify_archive
    raise ArchiveTAMInvalid()
borg.crypto.key.ArchiveTAMInvalid: Data integrity error: Archive authentication did not verify

Platform: Linux qwerty 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
Linux: Unknown Linux  
Borg: 1.2.7  Python: CPython 3.11.2 msgpack: 1.0.3 fuse: pyfuse3 3.2.1 [pyfuse3,llfuse]
PID: 1369927  CWD: /home/user
sys.argv: ['/usr/bin/borg', 'list', 'redacted at redacted:etc::m01']
SSH_ORIGINAL_COMMAND: None
--

It is still possible to create new repos, which check OK, but not to list the affected repos due to errors like the above.

Is this a bug?

I can't see anything relevant in the change log

https://borgbackup.readthedocs.io/en/stable/changes.html#upgrade-notes

I wonder if a borg upgrade would help, but I can't see a way to upgrade a remote keyfile-encrypted repo.

$ sudo ssh redacted at redacted borg upgrade -v etc
making a hardlink copy in /data1/home/redacted/etc.before-upgrade-2024-02-25-22:22:35
opening attic repository with borg and converting
no key file found for repository
converting repo index /data1/home/redacted/etc/index.91850
converting 74 segments...
converting borg 0.xx to borg current
no key file found for repository
$

This appears to fail, as the same output appears if the command is repeated - I presume because the keyfile is not provided - how can it be?

The problems disappear if borg client is reverted to 1.2.4

Any ideas what has happened or how to fix it would be much appreciated.

Thanks,
Gareth


From donotspam at fastmail.fm  Sun Feb 25 17:54:43 2024
From: donotspam at fastmail.fm (Gareth Evans)
Date: Sun, 25 Feb 2024 22:54:43 +0000
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
Message-ID: <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>

On Sun 25/02/2024 at 22:39, Gareth Evans <donotspam at fastmail.fm> wrote:
> I use borg client 1.2.4 on Debian bookworm with 1.2.7 on a FreeBSD 
> server, of which (the server) I am not in control.
>
> Repos are encrypted using local keyfiles, and were created quite some time ago.
>
> On the first day of the month, the last-day-of-last-month's repo is 
> converted to that month's archive for the year.  I have a script which 
> does:
>
> borg delete redacted at redacted:$repo::m$lastmonth
> borg rename redacted at redacted:$repo::d$yesterday m$lastmonth
>
> $ borg --version
> borg 1.2.4
> $ sudo borg check redacted at redacted:etc
> $
>
> After upgrading the client version to 1.2.7 from bookworm-backports, 
> problems are reported with the archives which have been renamed.
>
> --
> $ sudo borg check redacted at redacted:etc
> Archive TAM authentication issue for archive m07: Data integrity error: 
> Archive authentication did not verify
> This archive will be *removed* from the manifest! It will be deleted.
> Archive TAM authentication issue for archive m08: Data integrity error: 
> Archive authentication did not verify
> This archive will be *removed* from the manifest! It will be deleted.
> Archive TAM authentication issue for archive m09: Data integrity error: 
> Archive authentication did not verify
> This archive will be *removed* from the manifest! It will be deleted.
> Archive TAM authentication issue for archive m10: Data integrity error: 
> Archive authentication did not verify
> This archive will be *removed* from the manifest! It will be deleted.
> Archive TAM authentication issue for archive m11: Data integrity error: 
> Archive authentication did not verify
> This archive will be *removed* from the manifest! It will be deleted.
> Archive TAM authentication issue for archive m12: Data integrity error: 
> Archive authentication did not verify
> This archive will be *removed* from the manifest! It will be deleted.
> Archive TAM authentication issue for archive m01: Data integrity error: 
> Archive authentication did not verify
> This archive will be *removed* from the manifest! It will be deleted.
> 162 orphaned objects found!
> Archive consistency check complete, problems found.
> --
>
> Listing, for example, m01 produces
>
> --
> $ sudo borg list redacted at redacted:etc::m01
> Data integrity error: Archive authentication did not verify
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5343, in 
> main
>     exit_code = archiver.run(args)
>                 ^^^^^^^^^^^^^^^^^^
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5263, in 
> run
>     return set_ec(func(args))
>                   ^^^^^^^^^^
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 189, in 
> wrapper
>     return method(self, args, repository=repository, **kwargs)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1385, in 
> do_list
>     return self._list_archive(args, repository, manifest, key)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1414, in 
> _list_archive
>     _list_inner(cache=None)
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1402, in 
> _list_inner
>     archive = Archive(repository, key, manifest, args.location.archive, 
> cache=cache,
>               
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib/python3/dist-packages/borg/archive.py", line 488, in 
> __init__
>     self.load(info.id)
>   File "/usr/lib/python3/dist-packages/borg/archive.py", line 501, in 
> load
>     self.metadata = self._load_meta(self.id)
>                     ^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib/python3/dist-packages/borg/archive.py", line 493, in 
> _load_meta
>     archive, self.tam_verified, _ = 
> self.key.unpack_and_verify_archive(data, force_tam_not_required=True)
>                                     
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib/python3/dist-packages/borg/crypto/key.py", line 329, 
> in unpack_and_verify_archive
>     raise ArchiveTAMInvalid()
> borg.crypto.key.ArchiveTAMInvalid: Data integrity error: Archive 
> authentication did not verify
>
> Platform: Linux qwerty 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
> 6.1.76-1 (2024-02-01) x86_64
> Linux: Unknown Linux  
> Borg: 1.2.7  Python: CPython 3.11.2 msgpack: 1.0.3 fuse: pyfuse3 3.2.1 
> [pyfuse3,llfuse]
> PID: 1369927  CWD: /home/user
> sys.argv: ['/usr/bin/borg', 'list', 'redacted at redacted:etc::m01']
> SSH_ORIGINAL_COMMAND: None
> --
>
> It is still possible to create new repos, which check OK, but not to 
> list the affected repos due to errors like the above.
>
> Is this a bug?
>
> I can't see anything relevant in the change log
>
> https://borgbackup.readthedocs.io/en/stable/changes.html#upgrade-notes
>
> I wonder if a borg upgrade would help, but I can't see a way to upgrade 
> a remote keyfile-encrypted repo.
>
> $ sudo ssh redacted at redacted borg upgrade -v etc
> making a hardlink copy in 
> /data1/home/redacted/etc.before-upgrade-2024-02-25-22:22:35
> opening attic repository with borg and converting
> no key file found for repository
> converting repo index /data1/home/redacted/etc/index.91850
> converting 74 segments...
> converting borg 0.xx to borg current
> no key file found for repository
> $
>
> This appears to fail, as the same output appears if the command is 
> repeated - I presume because the keyfile is not provided - how can it 
> be?
>
> The problems disappear if borg client is reverted to 1.2.4
>
> Any ideas what has happened or how to fix it would be much appreciated.
>
> Thanks,
> Gareth
>
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup

I have just noticed the advice in

https://github.com/borgbackup/borg/blob/1.2.7/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811

but step 2 produces no output whatsoever, whereas some seems to be expected:

$ sudo ssh redacted at redacted BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug etc 2>&1 | grep TAM | grep -i manifest
$ 

What would be the recommended next step?

Thanks
Gareth

From donotspam at fastmail.fm  Sun Feb 25 18:12:15 2024
From: donotspam at fastmail.fm (Gareth Evans)
Date: Sun, 25 Feb 2024 23:12:15 +0000
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
Message-ID: <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>

On Sun 25/02/2024 at 22:54, Gareth Evans <donotspam at fastmail.fm> wrote:
> On Sun 25/02/2024 at 22:39, Gareth Evans <donotspam at fastmail.fm> wrote:
>> I use borg client 1.2.4 on Debian bookworm with 1.2.7 on a FreeBSD 
>> server, of which (the server) I am not in control.
>>
>> Repos are encrypted using local keyfiles, and were created quite some time ago.
>>
>> On the first day of the month, the last-day-of-last-month's repo is 
>> converted to that month's archive for the year.  I have a script which 
>> does:
>>
>> borg delete redacted at redacted:$repo::m$lastmonth
>> borg rename redacted at redacted:$repo::d$yesterday m$lastmonth
>>
>> $ borg --version
>> borg 1.2.4
>> $ sudo borg check redacted at redacted:etc
>> $
>>
>> After upgrading the client version to 1.2.7 from bookworm-backports, 
>> problems are reported with the archives which have been renamed.
>>
>> --
>> $ sudo borg check redacted at redacted:etc
>> Archive TAM authentication issue for archive m07: Data integrity error: 
>> Archive authentication did not verify
>> This archive will be *removed* from the manifest! It will be deleted.
>> Archive TAM authentication issue for archive m08: Data integrity error: 
>> Archive authentication did not verify
>> This archive will be *removed* from the manifest! It will be deleted.
>> Archive TAM authentication issue for archive m09: Data integrity error: 
>> Archive authentication did not verify
>> This archive will be *removed* from the manifest! It will be deleted.
>> Archive TAM authentication issue for archive m10: Data integrity error: 
>> Archive authentication did not verify
>> This archive will be *removed* from the manifest! It will be deleted.
>> Archive TAM authentication issue for archive m11: Data integrity error: 
>> Archive authentication did not verify
>> This archive will be *removed* from the manifest! It will be deleted.
>> Archive TAM authentication issue for archive m12: Data integrity error: 
>> Archive authentication did not verify
>> This archive will be *removed* from the manifest! It will be deleted.
>> Archive TAM authentication issue for archive m01: Data integrity error: 
>> Archive authentication did not verify
>> This archive will be *removed* from the manifest! It will be deleted.
>> 162 orphaned objects found!
>> Archive consistency check complete, problems found.
>> --
>>
>> Listing, for example, m01 produces
>>
>> --
>> $ sudo borg list redacted at redacted:etc::m01
>> Data integrity error: Archive authentication did not verify
>> Traceback (most recent call last):
>>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5343, in 
>> main
>>     exit_code = archiver.run(args)
>>                 ^^^^^^^^^^^^^^^^^^
>>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 5263, in 
>> run
>>     return set_ec(func(args))
>>                   ^^^^^^^^^^
>>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 189, in 
>> wrapper
>>     return method(self, args, repository=repository, **kwargs)
>>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1385, in 
>> do_list
>>     return self._list_archive(args, repository, manifest, key)
>>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1414, in 
>> _list_archive
>>     _list_inner(cache=None)
>>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1402, in 
>> _list_inner
>>     archive = Archive(repository, key, manifest, args.location.archive, 
>> cache=cache,
>>               
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   File "/usr/lib/python3/dist-packages/borg/archive.py", line 488, in 
>> __init__
>>     self.load(info.id)
>>   File "/usr/lib/python3/dist-packages/borg/archive.py", line 501, in 
>> load
>>     self.metadata = self._load_meta(self.id)
>>                     ^^^^^^^^^^^^^^^^^^^^^^^^
>>   File "/usr/lib/python3/dist-packages/borg/archive.py", line 493, in 
>> _load_meta
>>     archive, self.tam_verified, _ = 
>> self.key.unpack_and_verify_archive(data, force_tam_not_required=True)
>>                                     
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   File "/usr/lib/python3/dist-packages/borg/crypto/key.py", line 329, 
>> in unpack_and_verify_archive
>>     raise ArchiveTAMInvalid()
>> borg.crypto.key.ArchiveTAMInvalid: Data integrity error: Archive 
>> authentication did not verify
>>
>> Platform: Linux qwerty 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
>> 6.1.76-1 (2024-02-01) x86_64
>> Linux: Unknown Linux  
>> Borg: 1.2.7  Python: CPython 3.11.2 msgpack: 1.0.3 fuse: pyfuse3 3.2.1 
>> [pyfuse3,llfuse]
>> PID: 1369927  CWD: /home/user
>> sys.argv: ['/usr/bin/borg', 'list', 'redacted at redacted:etc::m01']
>> SSH_ORIGINAL_COMMAND: None
>> --
>>
>> It is still possible to create new repos, which check OK, but not to 
>> list the affected repos due to errors like the above.
>>
>> Is this a bug?
>>
>> I can't see anything relevant in the change log
>>
>> https://borgbackup.readthedocs.io/en/stable/changes.html#upgrade-notes
>>
>> I wonder if a borg upgrade would help, but I can't see a way to upgrade 
>> a remote keyfile-encrypted repo.
>>
>> $ sudo ssh redacted at redacted borg upgrade -v etc
>> making a hardlink copy in 
>> /data1/home/redacted/etc.before-upgrade-2024-02-25-22:22:35
>> opening attic repository with borg and converting
>> no key file found for repository
>> converting repo index /data1/home/redacted/etc/index.91850
>> converting 74 segments...
>> converting borg 0.xx to borg current
>> no key file found for repository
>> $
>>
>> This appears to fail, as the same output appears if the command is 
>> repeated - I presume because the keyfile is not provided - how can it 
>> be?
>>
>> The problems disappear if borg client is reverted to 1.2.4
>>
>> Any ideas what has happened or how to fix it would be much appreciated.
>>
>> Thanks,
>> Gareth
>>
>> _______________________________________________
>> Borgbackup mailing list
>> Borgbackup at python.org
>> https://mail.python.org/mailman/listinfo/borgbackup
>
> I have just noticed the advice in
>
> https://github.com/borgbackup/borg/blob/1.2.7/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811
>
> but step 2 produces no output whatsoever, whereas some seems to be expected:
>
> $ sudo ssh redacted at redacted 
> BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug etc 2>&1 
> | grep TAM | grep -i manifest
> $ 
>
> What would be the recommended next step?
>
> Thanks
> Gareth
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup

Decided to proceed with one repo as a test.

Step 3 produced no output either.

borg check still fails giving the same issues with the 1.2.7 client

From donotspam at fastmail.fm  Sun Feb 25 20:17:30 2024
From: donotspam at fastmail.fm (Gareth Evans)
Date: Mon, 26 Feb 2024 01:17:30 +0000
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
Message-ID: <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>

On Sun 25/02/2024 at 23:12, Gareth Evans <donotspam at fastmail.fm> wrote:

>>> $ sudo ssh redacted at redacted borg upgrade -v etc
>>> [...]
>>> converting borg 0.xx to borg current

This seems to be a very old repo version, and new repos seem to have the same (if precisely unspecified) version, despite being created with borg 1.2.7 on the server and 1.2.4 or 1.2.7 on client.  

$ sudo borg init -e keyfile redacted at redacted:test
Enter new passphrase: 
Enter same passphrase again: 
Do you want your passphrase to be displayed for verification? [yN]: 

<snip blurb>

$ sudo ssh redacted at redacted borg upgrade -v test
making a hardlink copy in /data1/home/redacted/test.before-upgrade-2024-02-26-00:51:36
opening attic repository with borg and converting
no key file found for repository
converting repo index /data1/home/redacted/test/index.1
converting 2 segments...
converting borg 0.xx to borg current
no key file found for repository
$

I am seeking support from the server provider to rule out service-specific issues, but if anyone can shed any light in the mean time, I would be grateful.

Thanks,
Gareth

From donotspam at fastmail.fm  Sun Feb 25 20:58:18 2024
From: donotspam at fastmail.fm (Gareth Evans)
Date: Mon, 26 Feb 2024 01:58:18 +0000
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
 <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
Message-ID: <49307e2e-8582-42cd-b8b3-9aef0b6ef6ce@app.fastmail.com>

The server support provider says the borg client receives v0.29 and a --remote-path option is available for v1.2.7

That was unexpected given that 

ssh user at server borg --version

reports v1.2.7 - but there we are.

I think it might be easier to let backups to new repos take the place of older archives over time, than to upgrade from such an early version - it doesn't seem to be possible to upgrade to v1.1 first, as the borg docs upgrade notes suggest.

Hope that might help someone in a similar situation.

Best wishes,
Gareth


From tw at waldmann-edv.de  Mon Feb 26 05:24:16 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Mon, 26 Feb 2024 11:24:16 +0100
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
 <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
Message-ID: <a68ce7d9-79e3-43d2-a0e1-cba22adae5a6@waldmann-edv.de>

>>>> $ sudo ssh redacted at redacted borg upgrade -v etc

The docs explicitly tell to NOT run borg upgrade except when the docs 
tell you to do so.


-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From tw at waldmann-edv.de  Mon Feb 26 05:29:15 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Mon, 26 Feb 2024 11:29:15 +0100
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
Message-ID: <fae48910-b223-4fae-aefd-17a11aacc2a2@waldmann-edv.de>


> $ sudo ssh redacted at redacted BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug etc 2>&1 | grep TAM | grep -i manifest

Please do that in 2 steps:

First do a root login to the machine you want to run the command on.

Then run the steps from the borg docs.


 > but step 2 produces no output whatsoever, whereas some seems to be 
expected:

2. Run: BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug 
<repo> 2>&1 | grep TAM | grep -i manifest

    a) If you get "TAM-verified manifest", continue with 3.
    b) If you get "Manifest TAM not found and not required", run
       ``borg upgrade --tam --force <repository>`` *on every client*.


If that gives no output, leave away the " | grep TAM | grep -i manifest" 
part and check the full output manually.


-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From tw at waldmann-edv.de  Mon Feb 26 05:37:56 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Mon, 26 Feb 2024 11:37:56 +0100
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
Message-ID: <f3d11a19-8079-4b0a-a054-828a37ba4f88@waldmann-edv.de>

> Step 3 produced no output either.

3. Run: BORG_WORKAROUNDS=ignore_invalid_archive_tam borg list 
--consider-checkpoints --format='{name} {time} tam:{tam}{NL}' <repo>

That should definitely give some output -- except if a repo does not 
contain any archives at all.

I verified all the commands in the upgrade notes in the docs, they 
worked. So make sure you enter them as given (and avoid adding any 
complexity with trying to do additional stuff in the same command line).


You need to get the manifest and archive TAMs fixed before running borg 
check --repair or borg will delete all archives that have an invalid TAM.

The root cause that renamed archives are listed with an invalid TAM is 
due to a bug in earlier borg versions and the bug is fixed in 1.2.7.


-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From tw at waldmann-edv.de  Mon Feb 26 05:42:51 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Mon, 26 Feb 2024 11:42:51 +0100
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <49307e2e-8582-42cd-b8b3-9aef0b6ef6ce@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
 <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
 <49307e2e-8582-42cd-b8b3-9aef0b6ef6ce@app.fastmail.com>
Message-ID: <bead53b2-e002-4aaa-b15e-bfda2bc0b402@waldmann-edv.de>

> The server support provider says the borg client receives v0.29 and a --remote-path option is available for v1.2.7

rsync.net is known to have that old borg as default (which is a bit 
unfortunate nowadays, but maybe hard to change).

> That was unexpected given that
> 
> ssh user at server borg --version
> 
> reports v1.2.7 - but there we are.

That's weird.

> I think it might be easier to let backups to new repos take the place of older archives over time, than to upgrade from such an early version - it doesn't seem to be possible to upgrade to v1.1 first, as the borg docs upgrade notes suggest.

I think you should be fine with existing repos after following the steps 
precisely (and use 1.2.7 on client AND server).



-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From donotspam at fastmail.fm  Mon Feb 26 09:47:03 2024
From: donotspam at fastmail.fm (Gareth Evans)
Date: Mon, 26 Feb 2024 14:47:03 +0000
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <a68ce7d9-79e3-43d2-a0e1-cba22adae5a6@waldmann-edv.de>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
 <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
 <a68ce7d9-79e3-43d2-a0e1-cba22adae5a6@waldmann-edv.de>
Message-ID: <9cf402a2-1b87-468c-bb8f-2f410c80eacc@app.fastmail.com>

On Mon 26/02/2024 at 10:24, Thomas Waldmann <tw at waldmann-edv.de> wrote:
>>>>> $ sudo ssh redacted at redacted borg upgrade -v etc
>
> The docs explicitly tell to NOT run borg upgrade except when the docs 
> tell you to do so.

Hi Thomas,

Thanks for this and your other emails.

Do you mean the following?

"When you do not need borg upgrade
Not every change requires that you run borg upgrade.
You do not need to run it when:
- moving your repository to a different place
- upgrading to another point release (like 1.0.x to 1.0.y), except when noted otherwise in the changelog
- upgrading from 1.0.x to 1.1.x, except when noted otherwise in the changelog"
https://borgbackup.readthedocs.io/en/stable/usage/upgrade.html

This suggested to me that borg upgrade is in some circumstances unnecessary, rather than that it should be avoided unless instructed.  If I have missed a stricter injunction, I would be grateful if you could point out where that is stated.  Is it otherwise (potentially) harmful?

Given what seem to be the complexities of upgrading repos from 0.29, not perhaps the least of which including:

"... borg create (since 1.0.0) uses bigger chunks by default than old borg or attic did, so the new chunks won?t deduplicate with the old chunks in the upgraded repository. See --chunker-params option of borg create and borg recreate."
https://borgbackup.readthedocs.io/en/stable/usage/upgrade.html

...I'm still giving serious thought to just creating new repos and letting the old ones die out, though upgrading would be an experience.

If I have time later in the week I will try to create some new (old) repos and replicate current (rename-related) issues and see if I can make progress.

Incidentally, yes it was rsync.net.  Support said:

"borg 1.2.7 is available on your system, you need to alter your command in 
order to use it, here's an example:

borg list --remote-path=borg1 redacted at redacted.rsync.net

You may continue to use borg 0.29 without any special modifications of 
your command."

I don't understand how this can be the case, if:

$ sudo ssh redacted at redacted.rsync.net borg --version
borg0 1.2.7
$ sudo ssh redacted at redacted.rsync.net borg1 --version
borg1 1.2.7

run the same binaries respectively as the borg client calling borg serve, for "plain borg" and "borg --remote-path=borg1 ..." - although there doesn't seem to be a way to determine the borg-at-the-server version using borg client (is there?), which would be telling :)

I did ask how that was achieved if actually true, but they have, at least as yet, not replied.

I wonder if they were referring to (or intended to refer to) the repo version. Given I am using the 1.2.4 client with apparently a 0.29 repo, the client seems to be backwards-repo-compatible, as indeed does 1.2.7 save for the renaming issue.

Thanks for your help and your work on borgbackup - it's fantastic.

Gareth


From borgbackup-list at thomas.freit.ag  Mon Feb 26 16:43:00 2024
From: borgbackup-list at thomas.freit.ag (borgbackup-list at thomas.freit.ag)
Date: Mon, 26 Feb 2024 22:43:00 +0100
Subject: [Borgbackup] Ignoring files
In-Reply-To: <878r3cd0db.fsf@uwo.ca>
References: <a0f92f59-b14e-4cb4-9bba-04186b2829bb@thomas.freit.ag>
 <6a3e91b1-27d3-46c2-8d30-6e5385ceb775@waldmann-edv.de>
 <878r3cd0db.fsf@uwo.ca>
Message-ID: <2210f00a-69c3-4cfd-aee9-8fe0c91cba35@thomas.freit.ag>

Hi Dan,

On 22.02.24 15:44, Dan Christensen wrote:
>>> /yetanotherpath/Maildir/.INBOX.Operating.backup/dovecot-uidlist.tmp:
>>> stat: [Errno 2] No such file or directory: 'dovecot-uidlist.tmp'
>>> ...
>>> terminating with warning status, rc 1
>>> Pattern file contains following lines (beside some others):
>>> - re:.*\.lock$
>>> - re:.*\.tmp$

>> Hmm, the regex patterns look correct. Strange.

> Could it be due to other lines in the patterns file?  The order matters,
> right?

Pattern file starts with some global includes and excludes:
# global includes
R /root
R /etc
# global excludes
! /proc
! /sys
! /dev
- /home/*/.cache/
- re:.*\.lock$
- re:.*\.tmp$

Backup directory /home is given on the commandline, there is no include specified after the first exclude in the pattern file.

> It's also probably worth mentioning that borg uses rc 1 for files
> changed and rc 2 for errors, so scripts can differentiate.

I'd like to get warnings to this kind of issue, just not for included files. Thus I'd prefer not to ignore specific non-zero exitcodes.

Regards,
Thomas

From borgbackup-list at thomas.freit.ag  Mon Feb 26 16:43:03 2024
From: borgbackup-list at thomas.freit.ag (borgbackup-list at thomas.freit.ag)
Date: Mon, 26 Feb 2024 22:43:03 +0100
Subject: [Borgbackup] Ignoring files
In-Reply-To: <6a3e91b1-27d3-46c2-8d30-6e5385ceb775@waldmann-edv.de>
References: <a0f92f59-b14e-4cb4-9bba-04186b2829bb@thomas.freit.ag>
 <6a3e91b1-27d3-46c2-8d30-6e5385ceb775@waldmann-edv.de>
Message-ID: <4ed1d330-2538-4c45-a500-76b54ceed6b8@thomas.freit.ag>

Hi Thomas,

On 22.02.24 12:42, Thomas Waldmann wrote:
>> /yetanotherpath/Maildir/.INBOX.Operating.backup/dovecot-uidlist.tmp: stat: [Errno 2] No such file or directory: 'dovecot-uidlist.tmp'
>  > ...
>> terminating with warning status, rc 1
>>
>> Pattern file contains following lines (beside some others):
>> - re:.*\.lock$
>> - re:.*\.tmp$
> 
> Hmm, the regex patterns look correct. Strange.
> 
> Maybe file a bug and include a minimal(!) script that reproduces the problem. Also include the borg version.

I've set up a backup to local disk (backing up only maildirs), which runs every 10 mins, to try to hit the issue more frequently. Pattern and options are reduced. Version is 1.2.6 at the 
client(Ubuntu packaged borg). I'll follow up, when I have gathered more information.

>> Unforturnately using a filesystem with snapshot capabilities (and taking a snapshot to backup from a stable source) is not an option for most of the systems I backup.

> Pity. Because the main problem of course is that the inbox is locked for a reason (activity in the mail files) and you could end up backing up an inconsistent state of the files in the worst 
> case.

In this specific case (dovecot index files), it is not a real issue. One reason more to get rid of those "false" alarms.

Regards,
Thomas

From donotspam at fastmail.fm  Mon Feb 26 23:03:50 2024
From: donotspam at fastmail.fm (Gareth Evans)
Date: Tue, 27 Feb 2024 04:03:50 +0000
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <9cf402a2-1b87-468c-bb8f-2f410c80eacc@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
 <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
 <a68ce7d9-79e3-43d2-a0e1-cba22adae5a6@waldmann-edv.de>
 <9cf402a2-1b87-468c-bb8f-2f410c80eacc@app.fastmail.com>
Message-ID: <363789f6-e2c2-42f3-bc3a-6f0f1217a538@app.fastmail.com>

On Mon 26/02/2024 at 14:47, Gareth Evans <donotspam at fastmail.fm> wrote:

> [re "0.29"] I wonder if they were referring to (or intended to refer to) the repo version. 

Still not sure about that, but rsync.net support has now confirmed that, indeed:

$ ssh ... borg --version 

gives the borg version running at the server :)

So from what I've read here and elsewhere, it seems the 1.2.7 client chokes for some operations on renamed archives from some old-version repos, at least for repo v0.29, but whatever (client or server) handles renaming in 1.2.7 doesn't induce the same issue(s) when renaming repos itself.

I think that's where we are...

If it is possible for a future version of borg upgrade to "just work" or not, as required, dealing idempotently with previous versions' issues, making any required checks and adjustments, that would be ideal.

Thanks again.  I will have another look at the issues, docs and suggestions.

Best wishes,
Gareth




From tw at waldmann-edv.de  Wed Feb 28 11:18:41 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Wed, 28 Feb 2024 17:18:41 +0100
Subject: [Borgbackup] Problems after borg client upgrade
In-Reply-To: <363789f6-e2c2-42f3-bc3a-6f0f1217a538@app.fastmail.com>
References: <3008f0ec-d4fd-4aa8-962f-38f28ea992f5@app.fastmail.com>
 <46873e87-8646-408c-a507-7ac9b59b8291@app.fastmail.com>
 <fb8990a4-fe46-4b80-b5c9-18e5cccb8e77@app.fastmail.com>
 <24a687b3-ad7d-4e23-8c13-1acfd6873dd0@app.fastmail.com>
 <a68ce7d9-79e3-43d2-a0e1-cba22adae5a6@waldmann-edv.de>
 <9cf402a2-1b87-468c-bb8f-2f410c80eacc@app.fastmail.com>
 <363789f6-e2c2-42f3-bc3a-6f0f1217a538@app.fastmail.com>
Message-ID: <f7a466a4-8ffe-4a73-9fbe-e1b933b9e020@waldmann-edv.de>

> So from what I've read here and elsewhere, it seems the 1.2.7 client
 > chokes for some operations on renamed archives from some old-version
 > repos,
 > at least for repo v0.29, but whatever (client or server) handles
 > renaming in 1.2.7 doesn't induce the same issue(s) when renaming
 > repos itself.

It's not the repo version, it is a buggy borg client version (up to and 
including 1.2.4, IIRC) not having TAM-authenticated these archives 
correctly at rename time.

That (and some other stuff, see top of the changelog) is fixed in 1.2.7.

These slightly inconvenient changes were needed to fix that CVE.


-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.

From tw at waldmann-edv.de  Fri Mar 29 19:27:38 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Sat, 30 Mar 2024 00:27:38 +0100
Subject: [Borgbackup] borg 1.2.8 released!
Message-ID: <e2bd01ef-d6a0-4240-8ca6-04506d9a6f39@waldmann-edv.de>

Just released borg 1.2.8 with some fixes and a simplified TAM auth repo 
upgrade procedure:

https://github.com/borgbackup/borg/releases/tag/1.2.8

-- 
GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393

From tw at waldmann-edv.de  Sun Mar 31 13:10:20 2024
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Sun, 31 Mar 2024 19:10:20 +0200
Subject: [Borgbackup] borg 1.4.0b2 released!
Message-ID: <eb80edd5-6934-48eb-8b4f-550267dbec5c@waldmann-edv.de>

Just released borg 1.4.0b2 so that borg users can help testing this.

Dist package maintainers may also want to look at this.

https://github.com/borgbackup/borg/releases/tag/1.4.0b2

-- 

GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393