Incremental Backup not working in ver. 0.11.3

[cando]

SBackup is configured to backup a local data directory on Ubuntu 10.04 (ext4) to a remote SAMBA share (Windows 7 Pro) doing every 7 days a full backup and daily an incremental backup (simple schedule or via cron)

Same behavior when doing backup on Ubuntu 10.10 x64 of a nfs mounted remote source to backup on local folder (both ext4).

The backup works so far, a full backup is created and sequential backups are marked and reported as .inc (incremental).
However the compressed files created contain always the full set of files - no incremental backup at all). So the file system gest blasted after a while because of the large backup sets.

The older version of sbackup does work as expected, but could not connect to SAMBA, so one has to mount the file system first and backup to the monted folder locally.

Affected Version: Simple Backup Suite 0.11.3

I hope this can be fixed soon somehow.

kind regards cando

[Jean-Peer Lorenz (peer.loz)]

Thank you for using SBackup and for taking the time reporting this bug.

In order to track down the cause of the problem some more information are required. Please answer the following questions:

* what distribution do you use?
I've understood correctly 10.04 Lucid and 10.10 Maverick, right?

* from where was it installed (PPA, from source)?
* Is the bug reproducible; does it happen every time?
* do you run sbackup as superuser (root) or as regular user?
* Do backups (incremental) work for you, when running a backup stored on local drive?
* If you set up a minimal profile (maybe just a single directory) and run a manual backup (1st full, 2nd incr.), does it work as expected?

At first glance, your specific error looks like an underlying problem to me (e.g. modified time stamps) not directly caused by SBackup.

Many thanks for your help.

[cando (cando0815-googlemail)]

I use it on 2 different machines:

One server with Ubuntu Lucid 10.04 x64, SBackup fresh installed from ppa
One workstation Ubunty Maverick 10.10 x64, SBackup installed / upgraded
directly from the distro package

On both machines the same error. incremental backups contain always full
file set (ver.1.5) as stamp in file ver in backup set.

Older backups (from ver stamp1.4) were all correct, full backup set
contains all files, incremental only changed content.

The bug is reproduceable, it happens all the time since the installation
of the new version on both machines.

I assume Sbackup runs as root (file permissions are set to owner root).
The UI is called via: gksu sbackup-config-gtk - so it is an elevated
user account. (after the upgrade the management UI
has completely disappeared from the System -> Administration Menus and I
have manually add the entries for
sbackup-config-gtk and sbackup-restore-gtk with elevated rights via gksu.)

related to your request: I have set up now a new profile (manual backup)
and tried on the same disk (different directories).
It seems to work, the first set contains all files, the subsequent sets
contain only the complete empty folder structures
(changed vs. ver. 1.4 - there were no empty folders) I have tried
immediately following 3 backups with this configuration
and the backup seems to work.

What are the criteria how sbackup decides that one file was modified and
needs to be backed up incrementaly?

I will do the test tomorrow again to see, if it still works after
reboots and clam av virus scans and I will mail you the results.

I have some questions regarding sbackup:

What happens if two sbackup jobs access the same folder / file from
different machines (e.g. for redundancy)?
Does sbackup modify the file system on backup somehow so the two jobs
bite each other if a user decides
to back up / copy the shared data himselve in the meantime?

Is it somewhere documented, how sbackup works and on what information it
relies and what changes it makes to the file system?

Many thanks

cando

On 01/12/2011 05:29 PM, Jean-Peer Lorenz wrote:
> Thank you for using SBackup and for taking the time reporting this bug.
>
> In order to track down the cause of the problem some more information
> are required. Please answer the following questions:
>
> * what distribution do you use?
> I've understood correctly 10.04 Lucid and 10.10 Maverick, right?
>
> * from where was it installed (PPA, from source)?
> * Is the bug reproducible; does it happen every time?
> * do you run sbackup as superuser (root) or as regular user?
> * Do backups (incremental) work for you, when running a backup stored on local drive?
> * If you set up a minimal profile (maybe just a single directory) and run a manual backup (1st full, 2nd incr.), does it work as expected?
>
> At first glance, your specific error looks like an underlying problem to
> me (e.g. modified time stamps) not directly caused by SBackup.
>
> Many thanks for your help.
>

[Jean-Peer Lorenz (peer.loz)]

Could you please try to backup a small set of files/directories in order to see if things work basically?

> What happens if two sbackup jobs access the same folder / file from different machines (e.g. for redundancy)?
It should not modify the files in a way that would cause another backup process to store unmodified files.

Thanks for your help.

[Howard Cheng (howard-cheng)]

I am experiencing the same symptoms but without samba and only on a single machine, and only one sbackup runs at a time I put my info in #722111 because that was the first bug that I found that was similar to mine, but I think this bug is more appropriate. Please see my reports there.

[Howard Cheng (howard-cheng)]

I set up a test profile for a directory containing only one file, and that seems to work...

Here is the tail end of a typical log file to indicate the problem. Notice that tar wrote a lot more than what "max free space" required says:

2011-04-02 07:43:44,827 - INFO: Summary of backup
2011-04-02 07:43:44,828 - INFO: Number of directories: 11383.
2011-04-02 07:43:44,828 - INFO: Total number of files: 91573.
2011-04-02 07:43:44,828 - INFO: Number of symlinks: 1038.
2011-04-02 07:43:44,828 - INFO: Number of files included in snapshot: 1554.
2011-04-02 07:43:44,829 - INFO: Number of new files (also included): 1165.
2011-04-02 07:43:44,829 - INFO: Number of files skipped in incremental snapshot: 90019.
2011-04-02 07:43:44,829 - INFO: Number of items forced to be excluded: 251.
2011-04-02 07:43:44,830 - INFO: Number of items to be excluded by config: 129.
2011-04-02 07:43:44,830 - INFO: Maximum free size required is '3017 MiB 224 KiB 357'.
2011-04-02 07:43:44,830 - INFO: Available disk size is '62707 MiB 680 KiB'.
2011-04-02 07:43:44,852 - INFO: Snapshot is being committed
2011-04-02 07:43:44,870 - INFO: Launching TAR to make incremental backup.
2011-04-02 08:54:54,646 - INFO: Leading '/' from member names were removed.
2011-04-02 08:54:54,647 - INFO: TAR returned a message: Total bytes written: 63111178240 (59GiB, 15MiB/s)
2011-04-02 08:54:54,647 - INFO: TAR has been finished successfully.

[Howard Cheng (howard-cheng)]

tar jtf files.tar.bz2 shows that every file on my system was included.

[Launchpad Janitor (janitor)]

[Expired for sbackup (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for sbackup because there has been no activity for 60 days.]