schrodinger's backup

[88artur88]

System Details

• fwbackups version:
  flatpak info com.diffingo.fwbackups

   fwbackups - A feature-rich, user-friendly backup program
  
      ID: com.diffingo.fwbackups
     Ref: app/com.diffingo.fwbackups/x86_64/stable
    Arch: x86_64
  Branch: stable
  Version: 1.43.8-rc2
  License: GPL-2.0-or-later
  Origin: flathub
  Collection: org.flathub.Stable
  Installation: system
  Installed: 16.5 MB
  Runtime: org.gnome.Platform/x86_64/45
     Sdk: org.gnome.Sdk/x86_64/45
  Commit: 5c10049bcb8b426f85e8e8c51a943018ff7b000e2b0e6bc015c76696a8e27fb0
  Parent: 8635b1d823392deec1c0dc4f5a7d8f31cd03120813a70a580e26eb037316d595
  Subject: Update dependencies to fix CVEs in cryptography, pyinstaller, and paramiko (39ccf573)
    Date: 2023-12-30 06:02:45 +0000
  

• OS name and version:
  Fedora Linux 39 (Workstation Edition) x86_64 Kernel: 6.6.8-200.fc39.x86_64

Issue description

backup is incomplete, fwbackup doesn't report an error.
Backup files are cut at ~1.6GB.

Bug details

Steps to Reproduce:

1. configure backup to use bzip2 or gzip
2. attemt to recover data form that file

Observed results: Unexpected EOF in archive

Expected results:

1. Complete and recovareble backup
2. Error reported when backup isn't successfull

If the fwbackups log has any relevant information, include a snippet below:

unfortunately IMPORTANT information about an error during backup process is MISSING from logs. 

[stewartadam]

Thanks for reporting - I'd like to collect a few more details, as if the backup started successfully then this is likely an error condition in the underlying tar/bz2 commands.

1. Is the issue consistently reproducible if you run a new backup, then attempt to restore?

2. What is the destination filesystem? Is it possible that disk is full?

3. Have you tried enabling debug logging in the preferences and running a backup? You should see the command it is executing which you can try running yourself, for example:

   example log output

   Dec 31 12:21:53 :: INFO : Using tar.gz: Must backup all paths at once - Progress notification will be disabled.
   Dec 31 12:21:53 :: DEBUG : Backing up path 1/1: /home/stewartadam/backuptest/data
   Dec 31 12:21:53 :: DEBUG : Running command: nice -n 0 tar cfz '/home/stewartadam/backuptest/destination/Backup-setname-2023-12-31_12-21.tar.gz' '/home/stewartadam/backuptest/data'
   Dec 31 12:21:53 :: DEBUG : Starting subprocess with PID 40156
   Dec 31 12:21:55 :: DEBUG : Subprocess with PID 40156 exited with status 0
   Dec 31 12:21:56 :: INFO : Finished automatic backup operation of set 'backuptest'
   

   In this case running:

   tar cfz '/home/stewartadam/backuptest/destination/Backup-setname-2023-12-31_12-21.tar.gz' '/home/stewartadam/backuptest/data'
   

   would let you directly observe the underlying backup command. I'd be curious to see what happens when you hit that ~1.6GB point.

4. What types of files are include in your backup set? (e.g. mostly documents? whole filesystem?)

[stewartadam]

@88artur88 I've been unable to reproduce this issue, I tried both with a 3GB set of source files as well as trying to run a backup for >1h in case it was related to a timeout - but on my F39 installation it worked as expected.

Feel free to re-open if you can provide any of the information above, but as I can't reproduce this to diagnose the issue I'll close this for now.