Plan: one client backing up to several independent servers

Development
1

I back up my main PC to two servers: a local one and an offsite DR server. The client can talk to more than one server, but it treats the LAN and internet connection as the same server, so settings, paths and restores get mixed up between them. This comes up regularly here, e.g. Multiple Internet Backup Servers ( Multiple Internet Backup Servers ), multiple servers and one client with different folders ( multiple servers and one client with different folders ) (settings get overwritten by whichever server did the last backup) and How client settings works with multiple servers ( How client settings works with multiple servers ).

I’ve built a client that handles any number of independent servers and have been running it on my own PC for a few days. I’d like your opinion before turning it into PRs.

What it does:

  • A server list on the client. Each server has its own name, identity, and “local (LAN)” and/or “internet” connection.
  • Each server’s backup settings are kept separately (intervals, retention, patterns, image volumes, Windows components). A server pushing its settings only changes its own.
  • Backup paths can be assigned to some servers only. A server’s default paths only go to that server.
  • Logs record which server they belong to.
  • Restore, “Access backups” and “Back up now” ask which server. The tray tooltip shows the last backup per server.
  • New settings window: the server table, with the selected server’s settings, paths, components and logs below it.

Server changes are small and backward compatible. There are two new capability bits: the client can ask a server for its settings (“SEND SETTINGS”), and the server announces when it does no file backups. Stock servers and stock clients keep working; I’ve tested against both.

I’d send it in three PRs: the server list and per-server settings first, then per-server paths and logs, then the new settings window.

Questions:

  1. Is this something you’d want upstream, and on 2.6.x?
  2. The new settings window is built in code. Should I also update settings.fbp, or is code fine?
2

Sry, forgot to mention this. But this is also something in the dev branch. So preferably merge this from dev into the 2.6.x branch.

The client GUI might not be present yet, so that would need to be done, I guess.

3

Thanks, I hadn’t seen that. I had a look at the client facets in dev. They cover the backend part: a settings folder per server (data_), backup paths per facet, one internet client per facet and restores per facet. They came in with the local file backup work (together with backup destinations, secrets and the ransomware canary), so bringing them to 2.6.x means either taking part of that along or separating the facet parts out.

My branch also has things facets don’t have yet: urbackupclientctl and GUI support, editing the server list on the client, logs per server, choosing the server for “Back up now” and “Access backups”, and the per-server capabilities.

Two ways I see:

  1. Port the facet parts from dev to 2.6.x (without local backups), then build the GUI and the parts above on top of facets.
  2. Use my implementation on 2.6.x, changed to dev’s layout (the data_ folders and the client_facets table), so dev and 2.6.x don’t drift apart.

If local backups are planned for 2.6.x later anyway I’d go with 1, otherwise 2. Which do you prefer?

4

I went ahead and rebuilt the multi-server client on top of your client facets from dev,

on the current 2.6.x. It is up as two draft pull requests for discussion:

Backend: Client for several servers, on client facets (draft for discussion) by ljlongwing · Pull Request #170 · uroni/urbackup_backend · GitHub

Tray UI: Tray UI for the client for several servers (draft for discussion) by ljlongwing · Pull Request #16 · uroni/urbackup_frontend_wx · GitHub

The backend one lists the choices I made and what is not good yet. No hurry, I mainly want to know whether this is a direction you would like to take.