Some files are skipped during recovery

Help
jacktrip
2012-01-10
2012-10-08
  • jacktrip
    jacktrip
    2012-01-10

    Areca Backup v7.2.3 skips some files when doing a recovery in some
    circumstances. The Log window shows no errors. The issue doesn't seem to be
    related to special characters within a filename or path length issues. When I
    tried to recovery just one file - one of the files that is skipped during a
    bulk recovery - the recovery was successful.

    Areca Backup v7.1.10 recovery works fine when tested on the same backup, so it
    seems there was a bug introduced somewhere between v7.1.10 and v7.2.3.

     
  • aventin
    aventin
    2012-01-10

    Hi
    Could you test with version 7.2.4 beta and tell me if the issue still occur ?
    (Recovery has been partially refactored in this version)

    Thanks

     
  • jacktrip
    jacktrip
    2012-01-10

    Thank you aventin for your prompt response :).

    I've done some more tests. It seems that the problem only occurs after a merge
    has been performed with some older versions (such as v7.2.3), but not with
    v7.2.4 Beta. Unfortunately, if a merge has already been performed with older
    versions, updating to v7.2.4 Beta might not fix damage that already occurred
    for merges that were performed with older versions.

    The following are three tests that I did. Between each test, all relevant
    state in the virtual machine was reverted, including the relevant Areca Backup
    target files. The Areca Backup target that I used is a target from v7.1.10
    that has no merge archives. Differences in target from default target
    settings: 1) all files are stored in same archive 2) ".Zip" extension added to
    filenames.

    Test #1:
    Installed Areca Backup v7.2.3. Imported target. Did a recovery in Logical
    view. All files were recovered properly. Did a merge. Did a recovery in
    Logical view. Some files were not recovered properly - no error message given.

    Test #2:
    Installed Areca Backup v7.2.4 Beta. Imported target. Did a recovery in Logical
    view. All files were recovered properly. Did a merge (involving same archives
    as in test #1). Did a recovery in Logical view. All files were recovered
    properly.

    Test #3:
    Installed Areca Backup v7.2.3. Imported target. Did a recovery in Logical
    view. All files were recovered properly. Did a merge (involving same archives
    as in test #1). Did a recovery in Logical view. Some files were not recovered
    properly - no error messages given. Installed Areca Backup v7.2.4 Beta. Did a
    recovery in Logical view. Got message "Some recovered files seem corrupted.
    See log for details." Log window shows a separate warning for each file that
    wasn't recovered: "WARNING - <file name=""> was not recovered ... it should
    have."

    If you're having trouble reproducing, make sure to test on files with paths
    containing character "#" and filenames containing characters "", "-", "{", or
    "}".

     
  • jacktrip
    jacktrip
    2012-01-15

    I've done some more testing of the merge function along the same lines as the
    last post, but this time with other versions of Areca Backup. Areca Backup
    7.2.0 and 7.2.1 do not have this issue. Areca Backup 7.2.2 and 7.2.3 do have
    this issue.

    There is a different merge issue that was fixed in 7.2.0. See http://sourcefo
    rge.net/projects/areca/forums/forum/587586/topic/3857754
    for more details.

    As a result of these tests, I will probably use either 7.2.0 or 7.2.1.

     
  • jacktrip
    jacktrip
    2012-01-16

    Steps to reproduce issue with Areca Backup 7.2.3, Java Runtime Environment v6
    Update 30 x86, and Windows 7 x64:

    Make a new target. Set the source to be an empty folder. Change Storage to
    "Store all files in the same archive". Check "Add .zip extension to
    filenames'.

    Within the empty source folder, add three files named exactly as follows
    (including capitalization):
    Access
    ADO.NET 1
    ADO.NET 2

    Do a full backup of this target.

    Within the source folder, add one file named exactly as follows (including
    capitalization):
    Bob

    There should now be four files in the source folder.

    Do an incremental backup of target.

    Merge the two archives, with "Keep deleted files" unchecked.

    Do a recovery of all files in the merged archive to a folder of your choice.

    These two files are recovered:
    Access
    Bob

    These two files should have been recovered but are missing:
    ADO.NET 1
    ADO.NET 2

     
  • jacktrip
    jacktrip
    2012-01-18

    This issue doesn't seem to occur in affected Areca Backup versions when the
    Storage setting is left at its default "Store all files in the same archive."

     
  • aventin
    aventin
    2012-01-19

    Hi

    There was indeed a bug in the recovery function of Areca (probably introduced
    in version 7.2.2). This bug has been fixed (as well as another one) in version
    7.2.4.
    When a 'merge' is performed by Areca, all archives to be merged are first
    recovered in a temporary location, and then merged into a single archive.
    That's why this recovery bug affected archives produced by merging with these
    versions of Areca.

    The recovery part was historically complex because two modes were implemented
    :
    - a first one - optimized in terms of I/O but that used a log of memory -> not suitable when handling archives that contain a high number of files
    - another one - not optimized in termes of I/O but that used very few memory - suitable when handling large archives

    The combination of these two recovery modes made the code quite complex and
    not easy to maintain/test.

    As of v7.2.4, these two modes have been merged in a single one that is optimal
    in terms of I/O and that uses a limited amount of memory (regardless to the
    number of recovered files)

     
  • jacktrip
    jacktrip
    2012-01-19

    Thank you aventin for your explanation, and release of 7.2.4 final :).

    My last post had an error. It should have read "This issue doesn't seem to
    occur in affected Areca Backup versions when the given target's Storage
    setting is left at its default setting 'Store each file separately.'" Is this
    a true statement?