Feature Request: Retry (Failed) Scheduled Backups


Author
Message
APA
APA
Junior Member
Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)
Group: Forum Members
Posts: 27, Visits: 112
Greetings,

Some scheduled backup 'failures' are temporary in nature.  For example, if a source or target drive is not available at the time of the scheduled backup, it fails.   The source or target drive may be temporarily unavailable, and it would be useful if Reflect could 'retry' in such conditions.

Ideally the backup definition Retry Count (number of times Reflect should attempt to complete the backup) and Retry Delay (time between retry attempts) could be user specified per scheduled backup definition.

Thoughts?
Andrew
Beardy
Beardy
Expert
Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)
Group: Forum Members
Posts: 640, Visits: 2.4K
This isn't hard to arrange in a batch job or powershell script, though I'd argue it's better to arrange to test for such conditions before making the first try if you're operating where it's likely, usually also fairly straightforward.

I'm not opposed to the idea, in principle, it just seems unnecessary.
APA
APA
Junior Member
Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)
Group: Forum Members
Posts: 27, Visits: 112
Beardy - 17 February 2021 10:09 AM
This isn't hard to arrange in a batch job or powershell script, though I'd argue it's better to arrange to test for such conditions before making the first try if you're operating where it's likely, usually also fairly straightforward.

I'm not opposed to the idea, in principle, it just seems unnecessary.

Hello Beardy,
If we utilise scripts/programs there are virtually no limitations, however I'm suggesting a product improvement  (Retry Count and Retry Delay) only for failed scheduled backups.  
It this kind of option is available in Reflects Scheduled Backups Definition, we all get access to a 'standard' part of the product.  No external scripts/programs required.

It would be very handy to defined a scheduled backup with "If it fails, retry 3 times at 10 minute intervals".  With 2 check boxes Smile
Regards, Andrew


jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)Macrium Evangelist (22K reputation)
Group: Forum Members
Posts: 14K, Visits: 84K
I proposed an idea along these lines in this forum section a while ago: https://forum.macrium.com/22024/Opportunistic-backups-incl-resuming-interrupted-backups
Beardy
Beardy
Expert
Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)Expert (817 reputation)
Group: Forum Members
Posts: 640, Visits: 2.4K
As I said, I'm not opposed to the idea, even if working around it not being present is relatively straightforward.  I would, however, be wanting to see warnings logged for the failed attempts, so the job could be set up in a manner where it didn't routinely trigger retries.
Sander
Sander
New Member
New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)New Member (4 reputation)
Group: Forum Members
Posts: 1, Visits: 9
I would like this feature or perhaps if there is another way for me to achieve the following:

If a monthly full backup fails for any reason, such as network down, AC power not plugged in or PC off, then I do not want the scheduled backup to begin as soon as I start the PC the next morning to begin a day's work. Rather I would like the scheduled full backup to retry 24 hours later and continue to retry every 24 hours until: successful, the maximum number of retries has been reached, or the backup has been manually attempted (successful or not).

The main purpose of the delayed retry is to avoid the need for manual intervention and to avoid the backup slowing my computer down when I prefer to start the week with a responsive computer.

I agree it would be useful if after a certain number of failed retries, I get notified.

Can I already achieve this with a setting or script?

Any advice would be appreciated. Thanks.

Sander


APA
APA
Junior Member
Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)Junior Member (52 reputation)
Group: Forum Members
Posts: 27, Visits: 112
Sander - 8 August 2021 9:34 PM
I would like this feature or perhaps if there is another way for me to achieve the following:

If a monthly full backup fails for any reason, such as network down, AC power not plugged in or PC off, then I do not want the scheduled backup to begin as soon as I start the PC the next morning to begin a day's work. Rather I would like the scheduled full backup to retry 24 hours later and continue to retry every 24 hours until: successful, the maximum number of retries has been reached, or the backup has been manually attempted (successful or not).

The main purpose of the delayed retry is to avoid the need for manual intervention and to avoid the backup slowing my computer down when I prefer to start the week with a responsive computer.

I agree it would be useful if after a certain number of failed retries, I get notified.

Can I already achieve this with a setting or script?

Any advice would be appreciated. Thanks.

Sander


Hello Sander,
This is another good example that could be controlled by a new function 'Retry Count (number of times Reflect should attempt to complete the backup) and Retry Delay (time between retry attempts) could be user specified per scheduled backup definition.

Indeed, the automatic message could be sent after all Retry Attempts + Retry Delay were exhausted?

I perfer to avoid scripting solutions, far better to have Macrium coded to have the option(s).

Can anybody from Macrium Support comment?

JK
JK
Macrium Hero
Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)
Group: Forum Members
Posts: 1.5K, Visits: 6K
Just wanted to say that I support either (or both) of the ideas proposed by APA and JP.  It would be nice to have some kind of scheduling support for situations in which the availability of the destination drive is unpredictable/sporadic.

                                
ripwit
ripwit
New Member
New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)New Member (9 reputation)
Group: Forum Members
Posts: 2, Visits: 25
Beardy - 17 February 2021 10:09 AM
This isn't hard to arrange in a batch job or powershell script, though I'd argue it's better to arrange to test for such conditions before making the first try if you're operating where it's likely, usually also fairly straightforward.

I'm not opposed to the idea, in principle, it just seems unnecessary.

The problem with externally scripting these retry operations is that the script(s) would now also have to know which media were going to be needed. Perhaps that's obtainable from the configuration files but that means additional parsing and processing with resulting fragility.

I unplug my backup media (USB external drives) after the daily incrementals and plug them back in before the backup starts (if I remember). I don't like leaving backup media sitting on the system where it might be (in)advertently damaged.
JK
JK
Macrium Hero
Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)Macrium Hero (2.4K reputation)
Group: Forum Members
Posts: 1.5K, Visits: 6K
The problem with externally scripting these retry operations is that the script(s) would now also have to know which media were going to be needed.

Can you explain why you feel that this knowledge would be necessary (unless you are storing your XML file on the destination media, which is not recommended)?

                                
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search