Comments (19)
masc3d
commented on June 15, 2024
can you please provide kernel & btrfs-progs version for both systems
from btrfs-sxbackup.
masc3d
commented on June 15, 2024
latest versions I have currently in use are
Linux 5.3.9-gentoo #1 SMP GNU/Linux
btrfs-progs v5.3.1
and those work fine.
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
5.3.6-300.fc31.x86_64
btrfs-progs v5.4
on both systems
from btrfs-sxbackup.
masc3d
commented on June 15, 2024
this should be ok, basically.
also I don't believe the additional slash would be a problem.
can you check if this occurs on a entirely new backup job / destination volume?
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
Ok. As it is a production system I cannot use real drives (all drives are in use) but I can test using files with loop mount.
First I create a volume on the source machines and mount it.
[root@gilching1 ~]# dd if=/dev/zero of=./tmpvol bs=2M count=0 seek=1024
[root@gilching1 ~]# ls -l tmpvol
-rw-r--r--. 1 root root 2147483648 8. Jan 08:49 tmpvol
[root@gilching1 ~]# mkfs.btrfs tmpvol
btrfs-progs v5.4
See http://btrfs.wiki.kernel.org for more information.
Label: (null)
UUID: c8dc332c-ff8d-4708-ae80-82d63d635ace
Node size: 16384
Sector size: 4096
Filesystem size: 2.00GiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 102.38MiB
System: DUP 8.00MiB
SSD detected: no
Incompat features: extref, skinny-metadata
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 2.00GiB tmpvol
[root@gilching1 ~]# mkdir /mnt/tst
[root@gilching1 ~]# mount ./tmpvol /mnt/tst
[root@gilching1 ~]# mount | grep tst
/root/tmpvol on /mnt/tst type btrfs (rw,relatime,seclabel,space_cache,subvolid=5,subvol=/)
On the source volume I create a testfile.
[root@gilching1 ~]# touch /mnt/tst/testfile
[root@gilching1 ~]# ls -l /mnt/tst/testfile
-rw-r--r--. 1 root root 0 8. Jan 08:57 /mnt/tst/testfile
On the destination machine I create a volume the same way.
[root@gilching2 ~]# dd if=/dev/zero of=./tmpvol bs=2M count=0 seek=1024
[root@gilching2 ~]# mkfs.btrfs ./tmpvol
btrfs-progs v5.4
See http://btrfs.wiki.kernel.org for more information.
Label: (null)
UUID: dc456425-3b14-4eb5-92b6-965237f1c6b2
Node size: 16384
Sector size: 4096
Filesystem size: 2.00GiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 102.38MiB
System: DUP 8.00MiB
SSD detected: no
Incompat features: extref, skinny-metadata
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 2.00GiB ./tmpvol
[root@gilching2 ~]# mkdir /mnt/tst
[root@gilching2 ~]# mount ./tmpvol /mnt/tst
[root@gilching2 ~]# mount | grep tst
/root/tmpvol on /mnt/tst type btrfs (rw,relatime,seclabel,space_cache,subvolid=5,subvol=/)
[root@gilching2 ~]# ls -l /mnt/tst/
insgesamt 0
Everything looks ok so far. Source and destination volumes are mounted, source contains one file, destination is empty.
Now I set up the backup job the same way as I did for the production volume.
[root@gilching2 ~]# btrfs-sxbackup init ssh://gilching1:/mnt/tst/ /mnt/tst
INFO btrfs-sxbackup v0.6.11
INFO preparing source and destination environment
INFO source :: url [ssh://gilching1:/mnt/tst/] container [.sxbackup/] retention [10] compress [False]
INFO destination :: url [/mnt/tst/] retention [10] compress [False]
INFO initialized successfully
[root@gilching2 ~]# btrfs-sxbackup update -sr "3" -dr "30" /mnt/tst/
INFO btrfs-sxbackup v0.6.11
INFO updating configurations
UUID 653fc47a-4654-41cd-bd6c-c3f0b0af576b
Compress False
Source URL ssh://gilching1:/mnt/tst
Source info Linux 5.3.6-300.fc31.x86_64 #1 SMP Mon Oct 14 12:26:42 UTC 2019 GNU/Linux, btrfs-progs v5.4
Source container .sxbackup
Source retention 3
Destination URL /mnt/tst
Destination info Linux 5.3.6-300.fc31.x86_64 #1 SMP Mon Oct 14 12:26:42 UTC 2019 GNU/Linux, btrfs-progs v5.4
Destination retention 30
INFO updated successfully
Now I start the initial backup.
[root@gilching2 ~]# btrfs-sxbackup -vvv run /mnt/tst
INFO btrfs-sxbackup v0.6.11
DEBUG ['bash', '-c', 'if [ -f "/mnt/tst/.btrfs-sxbackup" ]; then exit 10; fi']
DEBUG ['bash', '-c', 'cat "/mnt/tst/.btrfs-sxbackup"']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'cat "/mnt/tst/.sxbackup/.btrfs-sxbackup"']
INFO source :: url [ssh://gilching1:/mnt/tst/] container [.sxbackup/] retention [3] compress [False]
INFO destination :: url [/mnt/tst/] retention [30] compress [False]
INFO preparing environment
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'if [ ! -d "/mnt/tst/.sxbackup/" ]; then btrfs sub create "/mnt/tst/.sxbackup/"; fi']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs sub show "/mnt/tst/.sxbackup/"']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'if [ -d "/mnt/tst/.sxbackup/.temp"* ]; then btrfs sub del "/mnt/tst/.sxbackup/.temp"*; fi']
DEBUG ['bash', '-c', 'if [ ! -d "/mnt/tst/" ]; then btrfs sub create "/mnt/tst/"; fi']
DEBUG ['bash', '-c', 'btrfs sub show "/mnt/tst/"']
DEBUG ['bash', '-c', 'if [ -d "/mnt/tst/.temp"* ]; then btrfs sub del "/mnt/tst/.temp"*; fi']
INFO source :: retrieving snapshots
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs sub list -o "/mnt/tst/.sxbackup/"']
INFO destination :: retrieving snapshots
DEBUG ['bash', '-c', 'btrfs sub list -o "/mnt/tst/"']
INFO source :: creating snapshot
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs sub snap "/mnt/tst/" "/mnt/tst/.sxbackup/.temp.cfc2e3f80dc843219b039e0c7e25d421" && sync']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'touch "/mnt/tst/.sxbackup/.temp.cfc2e3f80dc843219b039e0c7e25d421"']
DEBUG source :: updating property [ro] of [/mnt/tst/.sxbackup/.temp.cfc2e3f80dc843219b039e0c7e25d421] to [true]
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs property set "/mnt/tst/.sxbackup/.temp.cfc2e3f80dc843219b039e0c7e25d421" ro true']
DEBUG ['bash', '-c', 'if [ -d "/mnt/tst/.temp.cfc2e3f80dc843219b039e0c7e25d421" ]; then exit 10; fi']
INFO source :: transferring snapshot
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'ionice -c3 btrfs send "/mnt/tst/.sxbackup/.temp.cfc2e3f80dc843219b039e0c7e25d421"']
DEBUG ['bash', '-c', 'type pv']
DEBUG ['bash', '-c', 'ionice -c3 btrfs receive "/mnt/tst/"']
600 B 0:00:00 [2,63KiB/s] [ <=> ]
DEBUG source :: moving file [/mnt/tst/.sxbackup/.temp.cfc2e3f80dc843219b039e0c7e25d421] -> [/mnt/tst/.sxbackup/sx-20200108-081349-utc]
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'mv "/mnt/tst/.sxbackup/.temp.cfc2e3f80dc843219b039e0c7e25d421" "/mnt/tst/.sxbackup/sx-20200108-081349-utc"']
DEBUG destination :: moving file [/mnt/tst/.temp.cfc2e3f80dc843219b039e0c7e25d421] -> [/mnt/tst/sx-20200108-081349-utc]
DEBUG ['bash', '-c', 'mv "/mnt/tst/.temp.cfc2e3f80dc843219b039e0c7e25d421" "/mnt/tst/sx-20200108-081349-utc"']
INFO backup sx-20200108-081349-utc created successfully in 00:00:06
Test if the snapshot has been created and the testfile is there.
[root@gilching2 ~]# ls -l /mnt/tst/
insgesamt 0
drwxr-xr-x. 1 root root 16 8. Jan 09:13 sx-20200108-081349-utc
[root@gilching2 ~]# ls -l /mnt/tst/sx-20200108-081349-utc/
insgesamt 0
-rw-r--r--. 1 root root 0 8. Jan 08:57 testfile
Everything ok so far.
Now the incremental backup. I didn't change the testfile, so no data should be transfered, just a new snapshot.
[root@gilching2 ~]# btrfs-sxbackup -vvv run /mnt/tst
INFO btrfs-sxbackup v0.6.11
DEBUG ['bash', '-c', 'if [ -f "/mnt/tst/.btrfs-sxbackup" ]; then exit 10; fi']
DEBUG ['bash', '-c', 'cat "/mnt/tst/.btrfs-sxbackup"']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'cat "/mnt/tst/.sxbackup/.btrfs-sxbackup"']
INFO source :: url [ssh://gilching1:/mnt/tst/] container [.sxbackup/] retention [3] compress [False]
INFO destination :: url [/mnt/tst/] retention [30] compress [False]
INFO preparing environment
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'if [ ! -d "/mnt/tst/.sxbackup/" ]; then btrfs sub create "/mnt/tst/.sxbackup/"; fi']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs sub show "/mnt/tst/.sxbackup/"']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'if [ -d "/mnt/tst/.sxbackup/.temp"* ]; then btrfs sub del "/mnt/tst/.sxbackup/.temp"*; fi']
DEBUG ['bash', '-c', 'if [ ! -d "/mnt/tst/" ]; then btrfs sub create "/mnt/tst/"; fi']
DEBUG ['bash', '-c', 'btrfs sub show "/mnt/tst/"']
DEBUG ['bash', '-c', 'if [ -d "/mnt/tst/.temp"* ]; then btrfs sub del "/mnt/tst/.temp"*; fi']
INFO source :: retrieving snapshots
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs sub list -o "/mnt/tst/.sxbackup/"']
INFO destination :: retrieving snapshots
DEBUG ['bash', '-c', 'btrfs sub list -o "/mnt/tst/"']
INFO source :: creating snapshot
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs sub snap "/mnt/tst/" "/mnt/tst/.sxbackup/.temp.aa34c6e6039d4ce4b517df4fab210655" && sync']
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'touch "/mnt/tst/.sxbackup/.temp.aa34c6e6039d4ce4b517df4fab210655"']
DEBUG source :: updating property [ro] of [/mnt/tst/.sxbackup/.temp.aa34c6e6039d4ce4b517df4fab210655] to [true]
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'btrfs property set "/mnt/tst/.sxbackup/.temp.aa34c6e6039d4ce4b517df4fab210655" ro true']
DEBUG ['bash', '-c', 'if [ -d "/mnt/tst/.temp.aa34c6e6039d4ce4b517df4fab210655" ]; then exit 10; fi']
INFO source :: transferring snapshot
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'ionice -c3 btrfs send -p "/mnt/tst/.sxbackup/sx-20200108-081349-utc" "/mnt/tst/.sxbackup/.temp.aa34c6e6039d4ce4b517df4fab210655"']
DEBUG ['bash', '-c', 'type pv']
DEBUG ['bash', '-c', 'ionice -c3 btrfs receive "/mnt/tst/"']
205 B 0:00:00 [1,10KiB/s] [ <=> ]
DEBUG source :: moving file [/mnt/tst/.sxbackup/.temp.aa34c6e6039d4ce4b517df4fab210655] -> [/mnt/tst/.sxbackup/sx-20200108-081623-utc]
DEBUG ['ssh', '-o', 'ServerAliveInterval=5', '-o', 'ServerAliveCountMax=3', 'gilching1', 'mv "/mnt/tst/.sxbackup/.temp.aa34c6e6039d4ce4b517df4fab210655" "/mnt/tst/.sxbackup/sx-20200108-081623-utc"']
DEBUG destination :: moving file [/mnt/tst/.temp.aa34c6e6039d4ce4b517df4fab210655] -> [/mnt/tst/sx-20200108-081623-utc]
DEBUG ['bash', '-c', 'mv "/mnt/tst/.temp.aa34c6e6039d4ce4b517df4fab210655" "/mnt/tst/sx-20200108-081623-utc"']
INFO backup sx-20200108-081623-utc created successfully in 00:00:06
Surprisingly this works.
So we need to work out the difference between the production system and this test. On the production system I already tried to reformat the destination volume and set up a new backup job the same way as I did in this test, but with no effect, the error is still there.
So the error must be at the source volume / machine.
First I take a look at the backup control files.
Production volume:
[root@gilching1 ~]# cat /mnt/storage-1/.sxbackup/.btrfs-sxbackup
[Source]
uuid = 1ddba582-955a-40d8-a025-8735bcde97b4
retention = 3
[root@gilching1 ~]#
Test volume:
[root@gilching1 ~]# cat /mnt/tst/.sxbackup/.btrfs-sxbackup
[Source]
uuid = 653fc47a-4654-41cd-bd6c-c3f0b0af576b
retention = 3
[root@gilching1 ~]#
Basically I can't see anything wrong here.
But: source and destination paths have different lengths in the production system and the same length in the test system. Don't know if this is important (obviously it shouldn't).
Let's change that length of the path in the test system on the source mount point
[root@gilching1 ~]# umount /mnt/tst/
[root@gilching1 ~]# mv /mnt/tst /mnt/tst-1
[root@gilching1 ~]# mount | grep tst
/root/tmpvol on /mnt/tst-1 type btrfs (rw,relatime,seclabel,space_cache,subvolid=5,subvol=/)
Edit the destination control file (/mnt/tst/.btrfs-sxbackup) accordingly
[Destination]
uuid = 653fc47a-4654-41cd-bd6c-c3f0b0af576b
source = ssh://gilching1:/mnt/tst-1/
source-container = .sxbackup/
retention = 30
And again, incremental backup works just fine on the test volume.
Any idea? Unfortunately I can't just reformat the source volume of the production system as easy.
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
On the source volume I already tried the following with no effect / no error output:
- Delete the last snapshot that is used for differential transfer (btrfs subvolume delete sx-...)
- btrfs scrub /mnt/storage-1/
- btrfs check --progress --readonly --force /dev/mapper/luks-storage-1
- btrfs balance /mnt/storage-1/
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
Now I see a difference between the production system and the test system.
Shouldn't the generation increase from snapshot so snapshot?
[root@gilching1 .sxbackup]# btrfs sub list /mnt/storage-1/
ID 3160 gen 31446 top level 5 path .sxbackup
ID 3323 gen 31304 top level 3160 path .sxbackup/sx-20191019-020002-utc
ID 3324 gen 31304 top level 3160 path .sxbackup/sx-20191022-020004-utc
ID 3331 gen 31304 top level 3160 path .sxbackup/sx-20191023-020003-utc
ID 7003 gen 31357 top level 3160 path .sxbackup/sx-20191128-173739-utc
[root@gilching1 .sxbackup]# btrfs sub list /mnt/tst-1/
ID 257 gen 23 top level 5 path .sxbackup
ID 258 gen 12 top level 257 path .sxbackup/sx-20200108-081349-utc
ID 259 gen 15 top level 257 path .sxbackup/sx-20200108-081623-utc
ID 260 gen 18 top level 257 path .sxbackup/sx-20200108-082844-utc
ID 261 gen 22 top level 257 path .sxbackup/sx-20200108-084101-utc
sx-20191023-020003-utc is the snapshot where it stopped working.
sx-20191128-173739-utc has been created by a full backup job after reformatting the destination drive. Obviously the generation counter was stuck at 31304, which should not happen, right?
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
The problem of the unreadable file looks a bit like this topic:
https://www.spinics.net/lists/linux-btrfs/msg54739.html
Problem of non incrementing generation numbers has been seen here:
https://bugs.launchpad.net/ubuntu/+source/btrfs-tools/+bug/1348430
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
I ran check on the source fs with no error:
[root@gilching1 ~]# btrfs check /dev/mapper/luks-storage-1
Opening filesystem to check...
Checking filesystem on /dev/mapper/luks-storage-1
UUID: c1d778af-9084-4fb1-a44f-7e13c5eeb0aa
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 3582491025408 bytes used, no error found
total csum bytes: 3492104360
total tree bytes: 5834817536
total fs tree bytes: 1882243072
total extent tree bytes: 159072256
btree space waste bytes: 590085421
file data blocks allocated: 4005289889792
referenced 4005289889792
from btrfs-sxbackup.
masc3d
commented on June 15, 2024
Obviously the generation counter was stuck at 31304, which should not happen, right?
it may when there are no changes, generation would be the same.
from btrfs-sxbackup.
masc3d
commented on June 15, 2024
Any idea? Unfortunately I can't just reformat the source volume of the production system as easy.
maybe it's sufficient to restore entire subvol eg via btrfs-sxbackup transfer or manual send / receive. then snap it into place for minimum downtime.
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
it may when there are no changes, generation would be the same.
There were no changes at the testsystem and generation incremented correctly. Also I'm quite sure there were a lot of changes between sxbackup/sx-20191022-020004-utc and sx-20191023-020003-utc. Normally a few hundrets to thousands of files change per day in that particular system. The snapshots were built on normal working days, it's nearly impossible that nothing has changed.
maybe it's sufficient to restore entire subvol eg via btrfs-sxbackup transfer or manual send / receive. then snap it into place for minimum downtime.
Hmm, I'll think about that. Until the next maintenance downtime window I'm wondering if there is anything that I can investigate to find the reason for the error. I mean shouldn't btrfs be able to find such an error on its own if some sort of check is performed?
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
I think, I figured it out.
First I executed all the commands manually.
Built a snapshot of the source volume, made the ro. Dumped the output of btrfs send -p to a file, transfered that to the destination machine (to /root/btrfs-dumpfile).
Tried to load that file into btrfs receive and got an error, that file o926824-31440-0 cannot be accessed.
Then executed
cat /root/btrfs-dumpfile | btrfs receive --dump > /root/btrfs-cmddump
Now I looked inside of /root/btrfs-cmddump and searched for o926824-31440-0.
And here I see this
mkfile ./.temp.bla123/o926824-31440-0
rename ./.temp.bla123/o926824-31440-0 dest=./.temp.bla123/bak/router/log/httpd/error.log-20200105
utimes ./.temp.bla123/bak/router/log/httpd atime=2020-01-08T14:02:47+0100 mtime=2020-01-05T00:00:01+0100 ctime=2020-01-08T14:02:47+0100
write ./.temp.bla123/o926824-31440-0 offset=0 len=49152
write ./.temp.bla123/o926824-31440-0 offset=49152 len=49152
write ./.temp.bla123/o926824-31440-0 offset=98304 len=49152
write ./.temp.bla123/o926824-31440-0 offset=147456 len=49152
write ./.temp.bla123/o926824-31440-0 offset=196608 len=49152
write ./.temp.bla123/o926824-31440-0 offset=245760 len=24002
set_xattr ./.temp.bla123/o926824-31440-0 name=security.selinux data=system_u:object_r:unlabeled_t:s0 len=33
chown ./.temp.bla123/o926824-31440-0 gid=1003 uid=1003
chmod ./.temp.bla123/o926824-31440-0 mode=660
utimes ./.temp.bla123/o926824-31440-0 atime=2020-01-06T03:05:18+0100 mtime=2020-01-04T23:15:57+0100 ctime=2020-01-06T03:05:18+0100
One cannot first create a file, than rename it and then try to access it with the name it had before renaming.
This is clearly a fail in the command stream of btrfs send. Lots of commands prior to this have the right order of commands and work properly. Maybe this is a multithreading issue???
from btrfs-sxbackup.
masc3d
commented on June 15, 2024
how old is the source volume / which btrfs version was it created with and was it converted from another filesystem eg ext4?
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
The source volume has been created directly with mkfs.btrfs. According to my bash history that was
3937 [05.08.19 18:14:20] mkfs.btrfs /dev/mapper/luks-storage-1
That is german time code, year 2019, Aug. 05th.
I don't know the version of btrfs at that point.
I'm quite sure, that was Fedora version 29, so we could take a look at the repository which btrfs version was current at that time. The last update before mkfs.btrfs was executed on that system was done on
system-upgrade upgrade | 2018-11-20 20:50
This is an offline system, so it is updated on a yearly basis
from btrfs-sxbackup.
masc3d
commented on June 15, 2024
I remember quirks with filesystems created by conversion and / or older versions at some point. but that's also been long ago.
since issue can't be replicated on a clean filesystem maybe it's more feasible to re-create source. or maybe a post on btrfs mailing list could be helpful in case you want to investigate in-depth.
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
In my oppinion the problem is in btrfs send or receive. I don't think it is in the filesystem itself. We only can't reproduce it as long as there are not a lot of files in the system. It looks like the error occurees rarely and randomly.
A failure in the filesystem itself can't give a wrong order of commands in the btrfs send stream, as this is created on the fly and temporary file names are created at runtime, so are the commands for renaming and their order with write, utimes, set_xattr and so on.
I'm going to post that issue on the btrfs mailing list. As soon as I have a link to that I'll post that here for reference.
from btrfs-sxbackup.
sme-gmbh
commented on June 15, 2024
Github issue tracker is preferred over mailing list, so here it is:
kdave/btrfs-progs#230
from btrfs-sxbackup.
masc3d
commented on June 15, 2024
okay thanks for the heads up. will close this one in favor of this issue then.
from btrfs-sxbackup.
Related Issues (20)
- Individual commands for local (`snapshot`) and remote transfer (`sync`) HOT 4
- No way to disable compression HOT 2
- Allow to disable ssh compression HOT 2
- Allow to specify ssh cypher HOT 5
- Backup not working unexpected EOF in stream HOT 4
- Destination retention is not applied HOT 2
- sxbackup uses pv when invoked by systemd timer. HOT 3
- Run a pre- script on remote source? HOT 5
- Btrfs-send resiliency in the presence of tcp connection drops HOT 1
- btrfs-sxbackup requires (but does not document) "ionice" on the target HOT 1
- Enable compression on destination only HOT 4
- Command to make instant snapshot only, to transfer it later HOT 4
- Add cli argument to force disable pv for launching in cron scripts HOT 1
- Add transferred snapshot data size to logs output HOT 1
- Missing destination url in ssh source .sxbackup/.btrfs-sxbackup config file HOT 6
- btrfs-sxbackup fails to update backup job with ssh source HOT 1
- add webhook support HOT 1
- Add "--proto 0" to send/receive HOT 2
- File contains no section headers HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from btrfs-sxbackup.