Can someone tell me, please :
a. Where do I find the cause of this error ? (is there a hidden log somewhere ?)
b. What the usecase is of restarting this Sync Copy within the second, which ran for almost 24 hours before it failed :

while no normal backup got a chance to start because of this sync copy itself running all the time.

To me it is obvious that it will fail again (it failed before too), and there shouldn't be priority to this Sync Copy over the normal backups.
Also, it now starts to feel a bit crazy that the whole of the copied files are undone (deleted again) just because something fails. Mind you please, there's just a bunch of copies of individual PC's in the Repository (being copied) and I have zero chance to find out the cause (other than wait for another 24 hours for it to fail without visible / obvious reason).

And how do I formally kill this Sync Copy job ??  (remember, this is Site Manager and I can't find any "kill" option anywhere anyway)
With this, also notice that the Schedule for it can't be shut off (contrary to the normal Backup Schedule, which can be shut off), so I am not even in the position to block a next restart without deleting the whole schedule.

Thanks for any answers,
Peter

Killing mrserver.exe isn't the answer; it "nicely" restarts right away again (wasn't it the promise to have 1 re-attempt ?) and the first thing it does is again throw out the sofar made copies (which were consistent for the PC's done completely).

Hi Peter,

If you look in c:\programdata\macrium\sitemanager\remotesync.log you will find detailed logging on the sync problem. The sync should not retry immediately after a failed job - if this continues to be a problem, please contact our support team so they can investigate.

If you need to run a sync outside the sync window times, there's a "Run Now" option in the sync section of the repositories page. A running sync can be cancelled from the dashboard.

The reason that failed syncs roll back is that for incremental and differential backups, there is a reliance on the other files in the backup chain and a partial sync could leave "holes" in the backup chain on the remote server, resulting in backups which can't be restored. We are actively improving the remote sync feature - in the next release there is the option to allow backups to happen during sync (for computers which have had all their changes uploaded or have no changes to upload).

Kind Regards,

Alex

Macrium Development

See our reviews on

Thank you kindly for your rseponse, Alex.


The reason that failed syncs roll back is that for incremental and differential backups, there is a reliance on the other files in the backup chain and a partial sync could leave "holes" in the backup chain on the remote server, resulting in backups which can't be restored.

I understand. But please allow me ... are you correct on that ? Look :



HA5, PCMENNO, PCRB3, RAM-OS, WS05, WS07 are individual PC's. Their consistent sets are maintained (very) nicely per directory, like the one from WS07 is shown here.
I can not imagine that something from WS07 refers to e.g. WS05 for its consistency (if you say it will, than you have a point :-).
Maybe you don't know that ALL of these are deleted again, when the Sync Copy fails ? Btw, the PC Directory names persist, the GUID directory names too, but they will all be emptied (at the next start of the Sync Copy).
So after 23.5 hours the last one fails somehow (emptying that would be logical to me) but the others are fine and should stay. That this (when they stay) is convenient for troubleshooting, because now I can re-do the last one which failed in maybe 2 hours. Now it takes the 23.5 (etc.) again ...

Kind regards,
Peter

PS: Will look up those logs. Thanks !!

I am afraid that looking into the logs can never work in my case.



All zero. Why ? I suppose because as soon as it errors, all (thus) restarts within a fraction of a second and re-initializes (the logs too).

From repomanager.log :



and this tells nothing because here I again killed the Service and next deleted the Repository for it (the remaining ERRORs will be about that). I had to, with this ever lasting loop ...

Btw, I decided to first let run the backups (past night) and will now re-attempt the backups not on that NAS but on a normal PC (with USB disk). Just trying to find a working means. When that all is running, I will continue with the Sync Copy again (which is too slow on the NAS (from-and-to) anyway).

Kind regards,
Peter

A running sync can be cancelled from the dashboard.




Ah, with that cross. I thought it would remove the whole data from the Dashboard and I never attempted it. But it kills the task. OK, I am thick.
Thanks.

+x

 

PeterSt - 31 July 2019 2:27 PM

Thank you kindly for your rseponse, Alex.


The reason that failed syncs roll back is that for incremental and differential backups, there is a reliance on the other files in the backup chain and a partial sync could leave "holes" in the backup chain on the remote server, resulting in backups which can't be restored.

I understand. But please allow me ... are you correct on that ? Look :



HA5, PCMENNO, PCRB3, RAM-OS, WS05, WS07 are individual PC's. Their consistent sets are maintained (very) nicely per directory, like the one from WS07 is shown here.
I can not imagine that something from WS07 refers to e.g. WS05 for its consistency (if you say it will, than you have a point :-).
Maybe you don't know that ALL of these are deleted again, when the Sync Copy fails ? Btw, the PC Directory names persist, the GUID directory names too, but they will all be emptied (at the next start of the Sync Copy).
So after 23.5 hours the last one fails somehow (emptying that would be logical to me) but the others are fine and should stay. That this (when they stay) is convenient for troubleshooting, because now I can re-do the last one which failed in maybe 2 hours. Now it takes the 23.5 (etc.) again ...

Kind regards,
Peter

PS: Will look up those logs. Thanks !!

Hi Peter,

You're correct about the sets being independent - however we took the design view that the remote copy of the repository should be a point in time copy of the repository. This is because for disaster recovery, it's best to have all backups as close in time as possible. If two servers have very closely related and interdependent data, it would be better to have a day old image of both than one image from today and one from yesterday, which is what could happen if remote sync "checkpointing" happened on a per-folder basis. It might also cause issues for configurations where partition C and other partitions on a computer are backed up separately. 

That said, the feature is fairly new and we are gathering feedback on how to improve it - allowing per-folder or per-computer checkpointing would be one improvement and we will most likely schedule that for a future release along with some option checkboxes to put it under user control.

Kind Regards,

Alex

Macrium Development

See our reviews on

+x

 

PeterSt - 31 July 2019 2:43 PM

I am afraid that looking into the logs can never work in my case.



All zero. Why ? I suppose because as soon as it errors, all (thus) restarts within a fraction of a second and re-initializes (the logs too).

From repomanager.log :



and this tells nothing because here I again killed the Service and next deleted the Repository for it (the remaining ERRORs will be about that). I had to, with this ever lasting loop ...

Btw, I decided to first let run the backups (past night) and will now re-attempt the backups not on that NAS but on a normal PC (with USB disk). Just trying to find a working means. When that all is running, I will continue with the Sync Copy again (which is too slow on the NAS (from-and-to) anyway).

Kind regards,
Peter

Hi Peter,

The remotesync.log file may appear as 0 sized in explorer, but have data in it. This is a quirk of Windows. You are right that when the service restarts, the logs are flushed. However if you can get the log just after failure, we can look at it and determine what is causing the repeated attempts, which is a bug

Kind Regards,

Alex

Macrium Development

See our reviews on

Hi Alex,

Thank you for the eloboration on the Sync consistency - I understand.
I am of the stance that when processes take "too long" they need a start-through feature, or, well, they take too long. So ... obviously this is about offsite backup and over the Internet it will take even longer. How big is the chance on a hicup ? What I'm saying is that you will never get the Sync Copy because it will always fail under way and it will always require a restart from the beginning.
I still agree with the consistency, but I'd say that further solutions exists for that.

My case ?  just stopped chasing it as a solution. I mean :
  However if you can get the log just after failure,
how do you envision that after an undetermined number of hours waiting ?
IOW, please think of some trick, like deleteting the repository behind the back of the run itself (when it runs). In that case it would be my estimate it won't restart (but up to you).

Right now I adhered the swapping of USB disks. But of course that is no solution to the "real time off site", so to speak, which I would like better. Still I would also like to try the solution of "making a backup of the backup" in smart sector fashion. It should work. And then something like : Make a Full Backup once in a while and take that to an other place, and from there do the Differentials and Incrementals to that same USB disk, now elsewhere. And I know, you didn't make the software for that, but ...
And oh, I love experimenting with this. It is only that it takes a lot of throughput time to test out ideas. And meanwhile you should keep your backups running. :-)

If you want me to try something, let me know. If it only doesn't require actively waiting for something to finish.

Kind regards,
Peter

A small addition :

Yesterday I typed that I had doubts about the priority arrangements of Image Backups vs Sync Copy. But I scratched that because I liked to stay nice. I still do. :-)
So ... the fact that the Sync Copy starts itself right away, is one. But the matter that no skipped image Backups start anywhere, is two and more important (IMHO). Thus :

- Sync Copy runs for 23 hours and goes well over the point that Image Backups should start (midnight);
- When I finally got rid of the restarting Sync Copies, no Image Backup starts (while something like that is advertised, right ?).

I know, we (I) worked against the formal procedures by killing the job in the first place and if that is the same Service as the one causing the Image Backups (but it it ?) then things get too nasty for you. But I would say that once finally the Sync Copy is out of the way, the normal Image backup should be able to start.

Would it have worked to delete that "tag" file which is there (for both the Image Backup and the Sync Copy as separate files) ? Maybe not, because in the end I did not delete that but still it somehow disappeared (I forgot the sequences by now - sorry).
Anyway, the past midnight all Image Backups ran again automatically. Maybe I did something myself to trigger that (working on it half of the day).

This is no dealbreaker and manually we can do a lot of things (even start the whole bunch in one go, I'd say). But I thought you should know it didn't go automatically.
Peter