Cockpit: check backup destination

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:


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).

1 Like

I Will try to implement It and then you can test it :slightly_smiling_face:

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 :stuck_out_tongue:

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 :slight_smile:


Two hints:

  • Do not check backup destination when saved into settings. This will allow to create every backup schedule/method, even when the target is not available
  • Add a Check Backup Destination toggle/command into Cockpit as a troubleshoot/test tool without review the configuration. If it fails it’s “normal” to review the backup configuration.

This arrangement fullfull these scenarios:

  1. Admin can create a schedule/method for backup every time wanted, no matter if there are available the resources (usb drive, cloud account, network share, user permissions for network share, and goes on) So in rapid deployment/setup of the server, Backup can be realized and it will be effective as soon as resources will be available.
    Also, don’t miss that if you want to create a… basic scheme for your server, most of these settings will be available on the backup config or clone of the server.
  2. Backup destination can be verified for review avoiding the access (and modification) of the schedule. Quite nice and fast during review, troubleshooting and audit. Output of the check should be quite more… detailed that the old line from Simon The Sorcerer “That doesn’t work”.

Don’t get me wrong, this suggestions do not fit all user and environment cases, but seems common sense to me…

1 Like

Don’t say it twice :slight_smile:

1 Like

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)

1 Like