VVEngine "If error occurs..." doesn't re-run when

[deriderj]

Hi,

I have several profiles that are run using VVEngine. These profiles are backing up data across the Internet through a VPN connection. The profile is setup to rerun if an error occurs (After 15 minutes, 15 times max). After the profile successfully runs there is a dependent profile that starts. The dependent profile takes data from a staging area put there by the first profile and copies it to the final target directories.

My problem is that I frequently get an error while running the 1st profile that states the job was cancelled by the user (although it was not) and ends with a return code of 4. This is usually accompanied by an error about "has timestamp identifier in the future" and that a copy did not occur. When this "user canceled" AND "return code" = 4" occurs the profile is not re-run. Because the re-run never occurs that profile never completes that day with a return code 0 and the 2nd profile is never executed.

What changes can I make in VVEngine or in the Profile that will force the job to re-run when this error occurs? I honestly don't think the error is valid because when I look at the time stamps nothing seems amiss; but the fact is I don't care about that; I just want the profile to re-run because I know that a re-run will not experience the error (when re-run manually it will finish with a return code 0) and will allow the 2nd profile to run.

The only thing I have attempted so far is to check "Ignore up to 60 second difference between files" in the profile settings but that did not change the frequency of this specific error.

Here is a snippet of the actual log showing the error(s) resulting in a profile ending with a return code of 4 but not re-running as expected:

2008-02-14 05:35:49 : -- Checking archive folder ...
2008-02-14 05:36:17 : [ERROR] Backup file "\\.host\shared folders\dr archive\.host\shared folders\dr data\d dickspc\zir\hfact25d.dbs_(2008-02-14_03-18-49_ove_t).dbs" has timestamp identifier in the future. File ignored. If you want to remove it, you need to remove it manually.
2008-02-14 05:36:18 : [ERROR] Backup file "\\.host\shared folders\dr archive\.host\shared folders\dr data\d dickspc\zir\hfactd.dbs_(2008-02-14_03-18-49_ove_t).dbs" has timestamp identifier in the future. File ignored. If you want to remove it, you need to remove it manually.
2008-02-14 05:36:18 : [ERROR] Backup file "\\.host\shared folders\dr archive\.host\shared folders\dr data\d dickspc\zir\hstat.dbs_(2008-02-14_03-18-49_ove_t).dbs" has timestamp identifier in the future. File ignored. If you want to remove it, you need to remove it manually.
2008-02-14 05:36:19 : [ERROR] Backup file "\\.host\shared folders\dr archive\.host\shared folders\dr data\d dickspc\zir\hstat25.dbs_(2008-02-14_03-18-49_ove_t).dbs" has timestamp identifier in the future. File ignored. If you want to remove it, you need to remove it manually.
2008-02-14 05:40:54 : Amount of files in target archive folder: 5193 (70.51GB)
2008-02-14 05:40:54 : Deleting file \\.host\shared folders\dr archive\.host\shared folders\dr data\j gncserver\company\lotus\AMREBAL.WK4_(2008-02-12_01-01-50_OVE_T).WK4 [OK].
2008-02-14 05:40:55 : -- Done: 1 (2.73MB) Err: 0 (0) Skipped: 0 (0) Tot: 103 (31.30MB) --
2008-02-14 05:40:55 : -- Objects Deleted per Second: 1.00 -- Elapsed Time: 0 sec
2008-02-14 05:40:55 : **> Execution canceled by User <**
2008-02-14 05:40:55 : Amount of files in target archive folder: 5192 (70.51GB)
2008-02-14 05:40:55 : Re-comparing ...
2008-02-14 05:40:55 : ---- Copying finished ----
2008-02-14 05:40:55 : ---- End ----
2008-02-14 05:40:55 : - Execution Summary -
2008-02-14 05:40:55 : - Added Files - Source: 0 (0) - Target: 19 (86.71MB)
2008-02-14 05:40:55 : - Updated Files - Source: 0 (0) - Target: 352 (3.80GB)
2008-02-14 05:40:55 : - Deleted Files - Source: 0 (0) - Target: 16 (85.09MB)
2008-02-14 05:40:55 : - Added Subfolders - Source: 0 - Target: 0
2008-02-14 05:40:55 : - Deleted Subfolders - Source: 0 - Target: 0
2008-02-14 05:40:55 : - Archive Information -
2008-02-14 05:40:55 : - Files Added to Archive - Source: 0 (0) - Target: 323 (153.19MB)
2008-02-14 05:40:55 : - Files Deleted from Archive - Source: 0 (0) - Target: 19 (130.33MB)
2008-02-14 05:40:55 : - Status Summary -
2008-02-14 05:40:55 : - Total Files - Source: 12,175 (29.35GB) - Target: 11,691 (25.62GB)
2008-02-14 05:40:55 : - Excluded Files - Source: 478 (5.24GB) - Target: 8 (1.60GB)
2008-02-14 05:40:55 : - Matched Files - Source: 11,646 (24.01GB) - Target: 11,646 (24.01GB)
2008-02-14 05:40:55 : - Single Files - Source: 14 (85.08MB) - Target: 0 (0)
2008-02-14 05:40:55 : - Newer Files - Source: 0 (0) - Target: 37 (11.58MB)
2008-02-14 05:40:55 : - Older Files - Source: 37 (11.64MB) - Target: 0 (0)
2008-02-14 05:40:55 : - Total Subfolders - Source: 44 - Target: 44
2008-02-14 05:40:55 : - Excluded Subfolders - Source: 0 - Target: 0
2008-02-14 05:40:55 : - Matched Subfolders - Source: 44 - Target: 44
2008-02-14 05:40:55 : - Single Subfolders - Source: 0 - Target: 0
2008-02-14 05:40:56 : Exit Code: 4. Execution canceled by user. [ERROR]

[TGRMN Software]

It does not re-run because exit code 4 is not considered an error (it is considered as manual termination) I am puzzled as to why you are getting that error message and that exit code ?!?
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[deriderj]

Thanks for the reply,

If a return code 4 is jus a warning and therefore does not cause a re-run then why does it prevent a dependent job from executing? The rules do not seem consistent to me…

Since the return code 4 being issued by ViceVersa is not severe enough to cause a re-run but is severe enough to stop a subsequent job from running within VVEngine the only option I would appear to have is to eliminate this error from occurring. I have tried to correct this error, but the fact is I don't know why the error is occurring. By all indications the files in question *do not* have a timestamp in the future.

To attempt to correct this error I enabled a daily update on both systems using atomic clock settings so that the systems run within 1/10th of a second of each other at all times. After making this change I deleted ALL archived data to ensure that the date / times on any subsequent archived files were as accurate as possible.

This error occurs at least 2 times a week on a daily run and so the disaster backup is corrupt at least 2 times a week. The whole point of the using ViceVersa and VVEngine is to provide stability of the backup process. A process that corrupts the data 28% of the time seems completely out of line with the objectives of these two integrated backup utilities.

I must find a solution to stop the continual corruption of backup data which is the result of the dependent profile not running when a return code 4 occurs in the 1st profile.

What information can I provide or what can I do that would help diagnose what is causing this error and more importantly to stop it from occurring?

Thank you.

[TGRMN Software]

I think this may be a bug because in the log file you posted I see the line

2008-02-14 05:36:17 : [ERROR] Backup file "\\.host\shared folders\dr archive\.host\shared folders\dr data\d dickspc\zir\hfact25d.dbs_(2008-02-14_03-18-49_ove_t).dbs" has timestamp identifier in the future. File ignored. If you want to remove it, you need to remove it manually.

the timestamp of the archive file is
2008-02-14_03-18-49
which is earlier than 2008-02-14 05:36:17 (the current time)

I also do not see why it would return error code 4, if it was not actually canceled by the user.

I think we will need to look at the ViceVersa source code for this one...
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[Guest]

Thanks for looking at this so closely. Please let me know if there is anything I can do to help with resolving this issue. Assuming that the problem can be resolved, do you think it will be a patch of some kind or do you think it is something that may be corrected in a subsequent release?