FS#61684 - Borgbackup recovery of files impossible
Attached to Project:
Community Packages
Opened by Uwe Graßhoff (White) - Friday, 08 February 2019, 21:33 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Saturday, 16 March 2019, 08:19 GMT
Opened by Uwe Graßhoff (White) - Friday, 08 February 2019, 21:33 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Saturday, 16 March 2019, 08:19 GMT
|
Details
Description:
Using borgbackup to backup the system to a different machine. This is working fine. But there is a problem when I'm trying to recover data from a backup. I can't open any of the backups. I'm using one console to mount the backup (which is working) then I switch into the mounted dir and do a "ls" to determine what snapshot I wan't to choose. Then I cd into this snapshot (regardless which snaphshot I use). The cd is also working without error. But then I do an "ls" to see the files in this backup and I get the error: ls: cannot open directory '.': Input/output error At the same time I get an traceback (see below). After this failed ls call I can't to anything in this mounted backup. also an "cd .." and after that "ls" is not working anymore. I need to unmount and than remount the backup the repdocue the behavior. Additional info: [root@whites-nb4 ~]# pacman -Q borg borg 1.1.8-1 [root@whites-nb4 ~]# pacman -Q |grep msgpack python-msgpack 0.6.1-1 Here is the console output of the two involved console sessions. ##### second console ###### [root@whites-nb4 ~]# borg mount -f $BORG_REPO borg Local Exception Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/borg/archiver.py", line 4436, in main exit_code = archiver.run(args) File "/usr/lib/python3.7/site-packages/borg/archiver.py", line 4368, in run return set_ec(func(args)) File "/usr/lib/python3.7/site-packages/borg/archiver.py", line 1353, in do_mount return self._do_mount(args) File "/usr/lib/python3.7/site-packages/borg/archiver.py", line 152, in wrapper return method(self, args, repository=repository, **kwargs) File "/usr/lib/python3.7/site-packages/borg/archiver.py", line 1363, in _do_mount operations.mount(args.mountpoint, args.options, args.foreground) File "/usr/lib/python3.7/site-packages/borg/fuse.py", line 340, in mount signal = fuse_main() File "/usr/lib/python3.7/site-packages/borg/fuse.py", line 34, in fuse_main return llfuse.main(workers=1) File "src/fuse_api.pxi", line 330, in llfuse.main File "src/handlers.pxi", line 436, in llfuse.fuse_opendir File "src/handlers.pxi", line 437, in llfuse.fuse_opendir File "/usr/lib/python3.7/site-packages/borg/fuse.py", line 581, in opendir self._load_pending_archive(inode) File "/usr/lib/python3.7/site-packages/borg/fuse.py", line 554, in _load_pending_archive self.process_archive(archive_name, [os.fsencode(archive_name)]) File "/usr/lib/python3.7/site-packages/borg/fuse.py", line 377, in process_archive consider_part_files=self.args.consider_part_files): File "/usr/lib/python3.7/site-packages/borg/fuse.py", line 160, in iter_archive_items item = unpacker.unpack(write_bytes) TypeError: unpack() takes no arguments (1 given) Platform: Linux whites-nb4 4.20.6-arch1-1-ARCH #1 SMP PREEMPT Thu Jan 31 08:22:01 UTC 2019 x86_64 Linux: arch Borg: 1.1.8 Python: CPython 3.7.2 PID: 29554 CWD: /root sys.argv: ['/usr/bin/borg', ##### second console ###### [root@whites-nb4 ~]# cd borg [root@whites-nb4 borg]# ls whites-nb4-2018-12-02T17:00:01 whites-nb4-2018-12-16T17:00:02 whites-nb4-2019-01-15T17:00:02 whites-nb4-2019-01-26T17:00:01 whites-nb4-2019-02-07T22:33:47 whites-nb4-2018-12-08T17:00:01 whites-nb4-2019-01-12T17:00:01 whites-nb4-2019-01-24T22:16:16 whites-nb4-2019-02-02T17:00:01 whites-nb4-2019-02-08T21:45:33 [root@whites-nb4 borg]# cd whites-nb4-2019-02-02T17\:00\:01/ [root@whites-nb4 whites-nb4-2019-02-02T17:00:01]# ls ls: cannot open directory '.': Input/output error Steps to reproduce: See console outputs. |
This task depends upon
Closed by Sven-Hendrik Haase (Svenstaro)
Saturday, 16 March 2019, 08:19 GMT
Reason for closing: Duplicate
Saturday, 16 March 2019, 08:19 GMT
Reason for closing: Duplicate
I think the downgrade should only be a temporary solution.