From list+borgbackup at datenwolf.net Wed Oct 4 05:48:15 2023 From: list+borgbackup at datenwolf.net (Wolfgang 'datenwolf' Draxinger) Date: Wed, 04 Oct 2023 11:48:15 +0200 Subject: [Borgbackup] Possibility to push-backup to remote through an intermediary proxy-cache? Message-ID: Hi, I'm wondering if there's a way to setup Borg in a way, that it performs push-backups through intermediary proxy-caches? __Motivation__ My current setup looks like this: I have several machines in the local network (laptop, desktop, etc.) which backup to Borg repositories hosted on SSD in my self-built edge router, which is then replicated to a Hetzner storage box. It's set up this way, due to the abysmally bad physical conditions of the telephone lines here, permitting some 15 MBit/s upload at most, so compared to the 1 GBit/s in the LAN that's a ~100? difference. Especially for mobile devices like laptops: 1 minute of Borg push equates to ~100 minutes in replication. This is working fine so far. However with additional devices in the network, and increasing storage capacity for each of them, I hit the capacity limit of the SSD in the router. I could ? of course ? go for a NAS. Trouble is: I've yet to find a NAS that meets my expectations; specifically I want this thing to draw significantly less than 10W while idle, so that it can passively cool while not doing "stuff", for audible noise reasons. __Idea__ Instead of keeping full repositories on the router SSD, use it as a cache for the push-backup deltas. Essentially I imagine it to happen like this: Machine A is pushing to remote repository R, where both ends are also talking to an intermediary proxy-cache C. A is coordinating with R to determine the actual delta, but pushing the data to C, which will then "drip-feed" it to R. The connection schemes I'm thinking of could look either like this +---+ <---------------> +---+ | | | | | A | fast slow | R | | | <---> +---+ | | +---+ ===>> | C | ===>> +---+ +---+ or this +---+ +---+ | | <---> +---+ <---> | | | A | fast | C | slow | R | | | ===>> +---+ ===>> | | +---+ +---+ <--->: control connection ===>>: push data transfer __Questions__ Is this something that can be implemented using Borgbackup? As far as I understand it (i.e. what I gather from the documentation, and some experiments), it's not (yet). Is this something that is worthwhile to look into implementing? If so, where to start and how to do it? Cheers, dw From tw at waldmann-edv.de Wed Oct 4 13:36:47 2023 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Wed, 4 Oct 2023 19:36:47 +0200 Subject: [Borgbackup] Possibility to push-backup to remote through an intermediary proxy-cache? In-Reply-To: References: Message-ID: <17b81e4d-900a-4c94-9c4b-d5c1061fac1a@waldmann-edv.de> Hi Wolfgang, did you try using borgbackup and directly backing up to a remote repo? Usually the first backup takes ages (but can be interrupted and continued as often as needed until it is finished), but the following backups usually go quick, even over slow connections. Of course it depends a bit on the amount of daily / hourly changes... I used borg for a long time with way less upload than you have now. I would advise against doing too complex setups - you can easily get into error propagation issues, partial replication issues, corrupted repos, etc. With borg 1.2 I'ld just configure multiple repos, per client at least: - one local repo one some other local machine with sufficient resources (rotated offline disks are a plus when it comes to stuff like crypto trojans) - one remote repo (that is used directly by the borg client) The local repo is for quick backups and restores, the remote repo is for redundancy and in case the local repo is not usable or lost. Of course directly backing up to the remote is slower than local, but if you do not produce large amounts of data each day, it should be doable. When using borg directly, you likely have less data to transfer compared to when rsyncing a borg repo (due to borg segment compaction shuffling data to new segments). borg is quite good at only uploading what's new - the more often you create a backup, the less "new" data there should be. With borg2 there might be more possibilities, like the concept of "related repos" (same key material), so an archive created in repo A can be transferred efficiently to repo B (there's a new "borg transfer" command). But borg2 is not released yet (currently in beta) and may still take quite a while, so that does not help you now. > Trouble is: I've yet to find a NAS that meets my > expectations; specifically I want this thing to draw significantly > less than 10W while idle, so that it can passively cool while not > doing "stuff", for audible noise reasons. That will be hard to do, esp. with scalable/reliable hardware. I use a Lenovo M75Q Gen2 + 2x 3.5" SATA Helium disks in a external 4x HDD case connected via USB. That is: - more than 10W, but less than what I had before *and* offering a lot of resources (for Proxmox, misc. VMs and containers, ZFS, ...). - not passively cooled, but silent enough for me (if there is no big load, the mini PC fan is not audible, but the HDD seeks are noticable). Of course one could use less HW (like only a single HDD, like a less powerful machine), but that's having more pain points. > Instead of keeping full repositories on the router SSD, use it as a > cache for the push-backup deltas. Essentially I imagine it to happen > like this: Machine A is pushing to remote repository R, where both > ends are also talking to an intermediary proxy-cache C. A is > coordinating with R to determine the actual delta, but pushing the > data to C, which will then "drip-feed" it to R. borg can't do that yet and there are a lot of other changes planned (and some already implemented) before something like that would be implemented, if ever. But guess with "borg transfer" of borg2, you could also get a similar user experience. Not for production yet, but the borg2 beta already has this, in case you want to play with it. Cheers, Thomas -- GPG Fingerprint: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393 From cata at geniusnet.ro Fri Oct 13 06:50:58 2023 From: cata at geniusnet.ro (Catalin Bucur) Date: Fri, 13 Oct 2023 13:50:58 +0300 Subject: [Borgbackup] TAM authentication issue Message-ID: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> Hello, I perform daily backups using the Borg client version 1.1.18 in a remote repository that is not under my control. All I know about it is that two versions are simultaneously offered: 1.1.18 and 1.2.4 (default). I perform weekly archive checks, and during the last one, I received a warning regarding the "Pre-1.2.5 archives spoofing vulnerability (CVE-2023-36811)": /"Archive TAM authentication issue for archive blocked_NX-2023-05-24T14:03:36: Data integrity error: Archive authentication did not verify This archive will be *removed* from the manifest! It will be deleted."/ What I would like to know is: ?- if I create a backup using client version 1.1.18 and I don't specify a version during the operation, in what way (version) will the data be written to the server, 1.1.18 or 1.2.4? ?- with access to the files created by Borg on the server, can I find out in which version they were written/saved? ?- why am I getting the warning if neither the client nor the server has a version greater than 1.2.4? ?- the solution to avoid losing those archives is to run the commands with the "BORG_WORKAROUNDS" switch, using client version 1.2.4? Thank you for your time. Best regards, -- Catalin Bucur -------------- next part -------------- An HTML attachment was scrubbed... URL: From nearduck at gmail.com Mon Oct 16 08:54:55 2023 From: nearduck at gmail.com (Salvatore Domenick Desiano) Date: Mon, 16 Oct 2023 08:54:55 -0400 Subject: [Borgbackup] CPU/memory reccomendation-requirements? Message-ID: I'm looking to run Borg server in a TrueNAS jail. The data is a plain OSX install, 10 TB of photos, videos, and archived disk images, a handful of medium-sized Git repositories, and one or two projects with large numbers (~1M) of small files (~2kb). It totals to around 15TB. I believe the TrueNAS requirements land me at basically any CPU that supports ECC and 16 GB of RAM. *What would you add to that to make sure the Borg server has enough room to breathe?* Thank you! -- Salvatore smile. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tw at waldmann-edv.de Mon Oct 16 10:48:42 2023 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Mon, 16 Oct 2023 16:48:42 +0200 Subject: [Borgbackup] TAM authentication issue In-Reply-To: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> References: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> Message-ID: <5705d971-9d5e-422f-989e-8540b5c4caa2@waldmann-edv.de> > I perform daily backups using the Borg client version 1.1.18 in a remote > repository that is not under my control. All I know about it is that two > versions are simultaneously offered: 1.1.18 and 1.2.4 (default). These versions do not yet know anything about this CVE: > I perform weekly archive checks, and during the last one, I received a > warning regarding the "Pre-1.2.5 archives spoofing vulnerability > (CVE-2023-36811)": > > /"Archive TAM authentication issue for archive > blocked_NX-2023-05-24T14:03:36: Data integrity error: Archive > authentication did not verify > This archive will be *removed* from the manifest! It will be deleted."/ This sounds like "borg check" from borg 1.2.6. Please read the 1.2.6 changelog and especially the CVE-related upgrade notes at top of the changelog. The steps you need to do are described there. > What I would like to know is: > ?- if I create a backup using client version 1.1.18 and I don't specify > a version during the operation, in what way (version) will the data be > written to the server, 1.1.18 or 1.2.4? 1.1.18 (because the TAM authentication happens clientside). > ?- with access to the files created by Borg on the server, can I find > out in which version they were written/saved? No. Usually they are even encrypted. > ?- why am I getting the warning if neither the client nor the server > has a version greater than 1.2.4? Well, I doubt that. The error msg you quoted does not exist in <= 1.2.4. Maybe you have multiple borg versions installed in misc. paths? Or some automated upgrade happened you did not notice yet? "borg -V" on the client side will tell you the version. Be careful: different users might have different search PATH set. > ?- the solution to avoid losing those archives is to run the commands > with the "BORG_WORKAROUNDS" switch, using client version 1.2.4? You need to run the commands from the upgrade notes in the changelog using borg >= 1.2.6. Versions <= 1.2.4 do not know all the commands needed. BTW, version 1.2.5 had issues, this is why I released 1.2.6 a day later. -- GPG Fingerprint: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393 Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt. From felix.schwarz at oss.schwarz.eu Mon Oct 16 14:30:48 2023 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 16 Oct 2023 20:30:48 +0200 Subject: [Borgbackup] TAM authentication issue In-Reply-To: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> References: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> Message-ID: Am 13.10.23 um 12:50 schrieb Catalin Bucur via Borgbackup: > > I perform daily backups using the Borg client version 1.1.18 in a remote > repository that is not under my control. All I know about it is that two > versions are simultaneously offered: 1.1.18 and 1.2.4 (default). just by chance: Are these versions really unmodified 1.1.18/1.2.4? For example if you run borgbackup on CentOS 7 with EPEL, you might see 1.1.18 but in reality it has quite a few patches on top. That might explain some of the messages you are seeing. Felix From nearduck at gmail.com Wed Oct 18 11:02:09 2023 From: nearduck at gmail.com (Salvatore Domenick Desiano) Date: Wed, 18 Oct 2023 11:02:09 -0400 Subject: [Borgbackup] CPU/memory reccomendation-requirements? In-Reply-To: References: Message-ID: FYI, I re-posted this on the Github discussion board ( https://github.com/borgbackup/borg/discussions/7878) which seems like the best place for Borg questions right now. On Mon, Oct 16, 2023 at 8:54?AM Salvatore Domenick Desiano < nearduck at gmail.com> wrote: > I'm looking to run Borg server in a TrueNAS jail. The data is a plain OSX > install, 10 TB of photos, videos, and archived disk images, a handful of > medium-sized Git repositories, and one or two projects with large numbers > (~1M) of small files (~2kb). It totals to around 15TB. > > I believe the TrueNAS requirements land me at basically any CPU that > supports ECC and 16 GB of RAM. > *What would you add to that to make sure the Borg server has enough room > to breathe?* > Thank you! > > -- Salvatore > smile. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cata at geniusnet.ro Thu Oct 19 05:33:24 2023 From: cata at geniusnet.ro (Catalin Bucur) Date: Thu, 19 Oct 2023 12:33:24 +0300 Subject: [Borgbackup] TAM authentication issue In-Reply-To: References: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> Message-ID: <6b5b049a-a468-4d45-9784-fec150bbe2e0@geniusnet.ro> On 16.10.2023 21:30, Felix Schwarz wrote: > > just by chance: Are these versions really unmodified 1.1.18/1.2.4? For > example if you run borgbackup on CentOS 7 with EPEL, you might see > 1.1.18 but in reality it has quite a few patches on top. That might > explain some of the messages you are seeing. > I don't really know this, but you may be right. # cat /etc/centos-release CentOS Linux release 7.9.2009 (Core) # /usr/bin/borg -V borg 1.1.18 # yum list borgbackup Installed Packages borgbackup.x86_64????????????????????? 1.1.18-2.el7?????????? @epel Thank you, Catalin Bucur From cata at geniusnet.ro Thu Oct 19 05:44:54 2023 From: cata at geniusnet.ro (Catalin Bucur) Date: Thu, 19 Oct 2023 12:44:54 +0300 Subject: [Borgbackup] TAM authentication issue In-Reply-To: <5705d971-9d5e-422f-989e-8540b5c4caa2@waldmann-edv.de> References: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> <5705d971-9d5e-422f-989e-8540b5c4caa2@waldmann-edv.de> Message-ID: On 16.10.2023 17:48, Thomas Waldmann wrote: > Well, I doubt that. > The error msg you quoted does not exist in <= 1.2.4. > > Maybe you have multiple borg versions installed in misc. paths? > Or some automated upgrade happened you did not notice yet? > > "borg -V" on the client side will tell you the version. > > Be careful: different users might have different search PATH set. > I suspect that the problem is related to what Felix Schwarz said, the borg executable in CentOS EPEL could be modified, even if it displays version 1.1.18 >> ??- the solution to avoid losing those archives is to run the >> commands with the "BORG_WORKAROUNDS" switch, using client version 1.2.4? > > You need to run the commands from the upgrade notes in the changelog > using borg >= 1.2.6. Versions <= 1.2.4 do not know all the commands > needed. > > BTW, version 1.2.5 had issues, this is why I released 1.2.6 a day later. > On CentOS 7 I also installed the borg executable version 1.2.4, but I don't know if it is better to run the command "borg upgrade --tam --force [...]" using the modified 1.1.18 version or would it be better with the "original" 1.2.4 version. And I also wonder if it is not too late to repair those archives, considering what is written in the docs and what means 1.1.18 modified version: "Do not run borg check with borg > 1.2.4 before completing the upgrade steps." Thank you, Catalin Bucur From felix.schwarz at oss.schwarz.eu Fri Oct 20 02:17:18 2023 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Fri, 20 Oct 2023 08:17:18 +0200 Subject: [Borgbackup] TAM authentication issue In-Reply-To: <6b5b049a-a468-4d45-9784-fec150bbe2e0@geniusnet.ro> References: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> <6b5b049a-a468-4d45-9784-fec150bbe2e0@geniusnet.ro> Message-ID: Am 19.10.23 um 11:33 schrieb Catalin Bucur via Borgbackup: >> just by chance: Are these versions really unmodified 1.1.18/1.2.4? For example >> if you run borgbackup on CentOS 7 with EPEL, you might see 1.1.18 but in >> reality it has quite a few patches on top. That might explain some of the >> messages you are seeing. >> > > I don't really know this, but you may be right. > ... > # yum list borgbackup > Installed Packages > borgbackup.x86_64????????????????????? 1.1.18-2.el7?????????? @epel That explains it, indeeed. Basically EPEL ships a subset of 1.1.x maintenance and you need to run the same upgrade commands as for newer versions: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f552ecb2a6 I could not test the full procedure with EPEL 7 because I did not have any affected repos. Felix From lazyvirus at gmx.com Wed Nov 8 11:56:48 2023 From: lazyvirus at gmx.com (Bzzzz) Date: Wed, 8 Nov 2023 17:56:48 +0100 Subject: [Borgbackup] No extended attributes from a backup sshfs mount Message-ID: <20231108175648.4f1e2cb9@msi.defcon1.lan> Hi borglisters, I use BB in push mode, from client to server, no BB instance running on the server. Client NFS mounts the server share where it's repo is located, then it writes it's new backup to this NFS mount, everything's fine either backups or restorations. The problem is, when client BB mount (sshfs) a remote backup and copy a file from it, the extended attributes are not preserved even with : "cp -a /SSHFS/file ." or "cp --preserve=xattr /SSHFS/file ." Until now, it did not really matter, but I'm writing an app that manipulates the extended attributes of some files, so in case of a restoration, they must be present. * Am I doing something wrong in the overall process ? * Am I wrong to think xattr should be preserved in this process ? * How can I (save ?) retrieve files with their xattr ? Jean-Yves Here are server and client setups : =================================== server : ======== /etc/fstab : ============ LABEL=2TB /2TB ext4 auto,user,defaults,noatime,acl,user_xattr,delalloc,nouid32 0 2 /2TB /NFS/2TB none bind 0 0 /etc/exports : ============== /NFS/2TB 192.168.1.0/24(rw,no_subtree_check,no_root_squash,sync) client : ======== /etc/fstab : ============ rpi:/2TB /NFS/2TB nfs user,noauto,nfsvers=4,hard,timeo=60,retrans=5,_netdev 0 0 borg sshfs mount (from my script) : =================================== borg mount "$BORG_REPO::$BACKUP" /SSHFS/ From tw at waldmann-edv.de Fri Nov 10 04:43:31 2023 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Fri, 10 Nov 2023 10:43:31 +0100 Subject: [Borgbackup] No extended attributes from a backup sshfs mount In-Reply-To: <20231108175648.4f1e2cb9@msi.defcon1.lan> References: <20231108175648.4f1e2cb9@msi.defcon1.lan> Message-ID: <5ab83e4f-d0a0-4cc6-8a22-01bafdee0fad@waldmann-edv.de> Does it work if you use borg extract instead of copying from a borgfs mount? -- GPG Fingerprint: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393 Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt. From lazyvirus at gmx.com Fri Nov 10 09:09:16 2023 From: lazyvirus at gmx.com (Bzzzz) Date: Fri, 10 Nov 2023 15:09:16 +0100 Subject: [Borgbackup] No extended attributes from a backup sshfs mount In-Reply-To: <5ab83e4f-d0a0-4cc6-8a22-01bafdee0fad@waldmann-edv.de> References: <20231108175648.4f1e2cb9@msi.defcon1.lan> <5ab83e4f-d0a0-4cc6-8a22-01bafdee0fad@waldmann-edv.de> Message-ID: <20231110150916.14d40f4a@msi.defcon1.lan> On Fri, 10 Nov 2023 10:43:31 +0100 Thomas Waldmann wrote: > Does it work if you use borg extract instead of copying from a borgfs > mount? > Hi, ZE problem is, I never used it, so I read the doc but it is missing extensive examples :/ Another thing is this repo only contains backups of the whole disk and I just need 4 files from it. After having a crash with a trace, I tried to extract 1 file into /tmp/ZZZZZZ/ : ============================================= borg --verbose extract --dry-run --pattern +etc/passwd $BORG_REPO::msi-2023-11-09T22:16:07Z /tmp/ZZZZZZ/ also tried with this file an absolute path : ============================================ borg --verbose extract --dry-run --pattern +/etc/passwd $BORG_REPO::msi-2023-11-09T22:16:07Z /tmp/ZZZZZZ/ but they both ended like that : =============================== Include pattern '/tmp/ZZZZZZ/' never matched. so I tried without the last /tmp/ZZZZZZ/ but I waited forever :( I'm stuck. Jean-Yves From cata at geniusnet.ro Wed Nov 15 10:47:30 2023 From: cata at geniusnet.ro (Catalin Bucur) Date: Wed, 15 Nov 2023 17:47:30 +0200 Subject: [Borgbackup] TAM authentication issue In-Reply-To: References: <1148ea8f-567c-4b0e-9acc-438eec581b63@geniusnet.ro> <6b5b049a-a468-4d45-9784-fec150bbe2e0@geniusnet.ro> Message-ID: <3d4c6a83-dee6-49d6-8000-ab24ad5874bf@geniusnet.ro> On 20.10.2023 09:17, Felix Schwarz wrote: > > Basically EPEL ships a subset of 1.1.x maintenance and you need to run > the same upgrade commands as for newer versions: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f552ecb2a6 > > I could not test the full procedure with EPEL 7 because I did not have > any affected repos. I've finished to run the steps from: https://github.com/borgbackup/borg/blob/1.2.5-cvedocs/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811 , using 1.1.18 version of borg from CentOS. Everything seems to be ok, thanks Felix & Thomas. Best regards, Catalin Bucur From tw at waldmann-edv.de Sat Dec 2 08:29:37 2023 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Sat, 2 Dec 2023 14:29:37 +0100 Subject: [Borgbackup] borg 1.2.7 release Message-ID: borgbackup 1.2.7 was just released! Details see there: https://github.com/borgbackup/borg/releases/tag/1.2.7 -- GPG Fingerprint: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393 From tw at waldmann-edv.de Mon Dec 4 11:39:50 2023 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Mon, 4 Dec 2023 17:39:50 +0100 Subject: [Borgbackup] No extended attributes from a backup sshfs mount In-Reply-To: <20231110150916.14d40f4a@msi.defcon1.lan> References: <20231108175648.4f1e2cb9@msi.defcon1.lan> <5ab83e4f-d0a0-4cc6-8a22-01bafdee0fad@waldmann-edv.de> <20231110150916.14d40f4a@msi.defcon1.lan> Message-ID: <84376f8a-4314-4626-8119-2ea93c1cc197@waldmann-edv.de> >> Does it work if you use borg extract instead of copying from a borgfs >> mount? >> > > Hi, > > ZE problem is, I never used it, so I read the doc but it is missing > extensive examples :/ Use borg list (and maybe grep) to get the precise filename/path you want to extract: borg list myrepo::myarchive | grep passwd Assuming it outputs this: etc/passwd Then you would do: mkdir temp ; cd temp borg extract myrepo::myarchive etc/passwd From lazyvirus at gmx.com Mon Dec 4 11:56:02 2023 From: lazyvirus at gmx.com (Bzzzz) Date: Mon, 4 Dec 2023 17:56:02 +0100 Subject: [Borgbackup] No extended attributes from a backup sshfs mount [SOLVED] In-Reply-To: <84376f8a-4314-4626-8119-2ea93c1cc197@waldmann-edv.de> References: <20231108175648.4f1e2cb9@msi.defcon1.lan> <5ab83e4f-d0a0-4cc6-8a22-01bafdee0fad@waldmann-edv.de> <20231110150916.14d40f4a@msi.defcon1.lan> <84376f8a-4314-4626-8119-2ea93c1cc197@waldmann-edv.de> Message-ID: <20231204175602.1a96f6b8@msi.defcon1.lan> On Mon, 4 Dec 2023 17:39:50 +0100 Thomas Waldmann wrote: > >> Does it work if you use borg extract instead of copying from a > >> borgfs mount? > >> > > > > Hi, > > > > ZE problem is, I never used it, so I read the doc but it is missing > > extensive examples :/ > > Use borg list (and maybe grep) to get the precise filename/path you > want to extract: > > borg list myrepo::myarchive | grep passwd Oh, I totally missed that 'list' could go down a level :/ > Assuming it outputs this: > > etc/passwd > > Then you would do: > > mkdir temp ; cd temp > > borg extract myrepo::myarchive etc/passwd Very easy indeed, once you know how to do it - everything's alright as: lsattr etc/passwd shows that the 'i' extended attribute is present :) I tagged your answer and also put it in my notes, so I won't forget the right way to restore a file. Thanks a lot Thomas. Jean-Yves