continue interrupted job

Hi,


I was wondering how interrupted jobs get continued. There is an option in the schedule dialog that should control the "continue", but the description also says "when the job is run again".

If one job gets interrupted by connection loss that has the option checked (DO continue), when will it actually continue? Right after connection is reestablished? When THIS job is scheduled to run again (which may be next day or next week), or when ANY job (which may be sooner) is started?


Also, how do seperate jobs coexist? When I have two jobs (to the same server), a big one that will take more than 24 hours and a small one that may take half an hour, what happens when the large one is still running when the small one's scheduled time arrives? Will the small job interrupt the big one? Will it be deferred? Or will it start in parallel?


Regards

Comments

  • If the profile is not stopped, then it will try again when the next scheduled time is reached.

    Only one profile will run at a time.  So if there is a long running profile then another profile will start only after the current one finished.
  • So to make sure the long, weekly profile gets completed eventually, I should still schedule it daily to make sure it has a chance to continue when interrupted, even though it doesn't do anything on most days?

    This is a problem when using the snapshot system: Each time the profile runs, it creates a new, dated target folder on the server. This is done even if there is nothing new  to be transfered. (Not a fault here, this is obviously as-designed.)

    The additional folders don't take up any space (their contents are linked-in from earlier copies), but they are irritating when looking for completed backups (partially completed transfers have their directory, too.)

    Is there a way around that?

    Regards
  • I don't know if there is an easy solution.  The directory is created by rsync as the sync job goes on so it will remain there when the job is interrupted.  You can't really delete the incomplete directory otherwise you would lose the ability to resume.

     
  • I'm still not clear about this:

    Yesterday morning, a big job was started.

    This morning (around 5 AM), the connection was broken and reestablished a few seconds later. The job was interrupted and did not continue.

    Two hours later (around 7 AM), the big job reached its daily schedule again. It was my expectation that it would continue where it had been interrupted before.

    Yet, the file that was in transfer when the connection was lost did not resume transfer and the log summary of the second attempt (this morning 7 AM) shows "Sent 0/0 bytes". So nothing resumed.

    But when I look at the rsync server, the file seems to be complete (judging from its size.) That must be why nothing was resumed. But then why did AcroSync report a transfer error, if the file had already been completed?


    Either there is now an incomplete file on the target, showing an illegal file size (which in fact it doesn't have), or the file has actually been transfered completly and the interruption-note from AcroSync is in error.


    NB: I have re-downloaded the file in question and compared it against its original. There were no differences, so the transfer seems to have completed. However, in the log it looks like this:

    [code]
    2018/03/15 05:26:10 RSYNC_UPLOAD Uploading data/
    2018/03/15 05:26:10 RSYNC_UPLOAD Uploading data/0e1255fa-8e04-4417-b6f9-502a122a3e0f.7z
    2018/03/15 06:11:27 SSH_ERROR SSH error: transport read
    2018/03/15 06:12:28 RSYNC_COMMAND rsync command: rsync --server --modify-window=2 [...]
    2018/03/15 06:12:28 RSYNC_PATTERN Add pattern: - /.acrosync/
    [...]
    [/code]


    Isn't this inaccurate when actually there was no error during transfer?

    Regards
  • It could be that the connection was broken after the file had been completely uploaded.  There was still some wrapping up to do, and if the connection failed at this stage Acrosync would think there was an error.
Sign In or Register to comment.