Sometimes, when backup fails, can be helpful for Sysadmin to check backup destination.
What do you think about adding “Check destination” into backup data menu like this?
If destination is reachable it will returns:
else:
If fails, it also return a ping to destination to check if it a credentials problem or a network problem.
What do you think?
I think it is a good idea to be able to check the backup destination like you can do while setting the backup.
About the ping, it shall depend on the backup method (if there’s something to ping or not).
I Will try to implement It and then you can test it 
You can do the same thing by clicking the “Edit” button. IMO there is no need of the same check using another button.
Regarding the ping, I thing it doesn’t make any real check. If you can ping a machine, it doesn’t mean you can access the backup destination (eg. example works, but sftp port is closed).
What about adding a “Check backup integrity” button? It requires much much more work, but it could be more useful. Be aware that It could be a very long running task.
In the end, I’m not sure the proposed feature is really usefull but it adds more code and … more bugs, as always 
What to you thing @dev_team?
As I’m understanding the suggestion, the ping happens only if the destination is not reachable, which makes sense as one of the first troubleshooting steps for a networked destination–if you can’t connect via NFS/SFTP/SMB, can you even reach the host at all?
I think that’s a good idea, but an orthogonal issue.
Check the destination backup is a good idea, but the ping is maybe not the good tool
I don’t interpret this as the ping being used to check the destination–I’m presuming the test would be to mount the backup path. It’s only if that fails that the ping is done, to see if the host is even reachable. And that seems a pretty sensible route to take; it’s about the first thing we’d recommend to troubleshoot a problem with connection to a remote server for backup.
Even in this case, the check doesn’t add any value.
If the last backup failed, the log should state the error. If the error is “Unreachable host”, it means the host was down at backup time not right now while I’m checking it. Thus, clicking on “Check destination” can tell you that the host is now online but not what really happened during the backup.
You can do a better check (is the host reachable and is the destination writable) just clicking on the “Edit” button.
Don’t get me wrong, we are really really pleased to receive contributions (see this thread as an example)! But we should avoid the feature bloat, especially on the core.
A patch like this one, will add roughly 200 lines of code which should be maintained by developers for years 
Two hints:
This arrangement fullfull these scenarios:
Don’t get me wrong, this suggestions do not fit all user and environment cases, but seems common sense to me…
Don’t say it twice
It needs an asynchronous task, an email must be sent to the admin with the result of the backup integrity
Like backup-data (in cockpit you see that is running)
