I apologize if this has been covered already, I did not find a general overview of how to use kopia server. I have it setup and working with the server running on it’s own machine, and I’m doing a test from my personal workstation before moving my servers over to using the centralized repository server.
I guess what I’m missing is, where does kopia run on the clients? Do I just keep a list of the directories I’m backing up and run
kopia snapshot [dir] for each one from cron or something?
Currently I run kopia on the machine that has the data to backup, connecting directly to the underlying storage, but it’s a little cumbersome as I end up with kopia server instances scattered all over my network. In that scenario, the server manages the snapshot schedule that I configure in the web UI.
How and where does that happen when I use kopia server?
No, its the other way around, actually. You install Kopia Server on one host, preferreably the one, which has the storage attached, but that is not a requirement. Then you run Kopia “clients” on your hosts on the network and have them connect to the Kopia server, where they shall push the sapshots to.
Depending on your hosts, you’ll manage your snapshots either via Cron or Kopia UI. You will then end up with one source on the Kopia server for each snapshot - usually one per host, but that also depends on your needs.
Thank you for your reply budy.
Let’s say I have a server S and two clients A and B, both of which are backing up local folders.
Where do the backup sets for A and B live, and how are they scheduled? Am I still running a kopia daemon on them, even if it’s not a server?
The Kopia CLI doesn’t include any scheduling - backups are basically a oneshot execution. But the GUI includes scheduling and does everything for you.
Sorry if I’m just unusually dense, but I still don’t get it.
The Kopia CLI doesn’t include any scheduling - backups are basically a oneshot execution.
That was my suspicion, it’s good to know for sure.
But the GUI includes scheduling and does everything for you.
Sticking with my example (server S, clients A and B), is the recommendation to run the GUI as a daemon on A and B, after configuring them to use server S, and then configure the backups via two separate web interfaces on those hosts?
The GUI is a wrapper around the CLI. You don’t need to run it as a daemon - it already includes the scheduling as part of the package. You launch the GUI as you normally would and after setting it up, it should work as intended. Note that the GUI can be minimized to tray (which is the default behaviour I think) so it will be in the background creating snapshots as needed. The CLI is the one that doesn’t have scheduling by itself. You can run the CLI without the GUI, and it can be useful if it is part of a bigger suite of tools you run, but it isn’t as user friendly.
So going back to your example, here is a setup that you create:
- On your
Server S, launch kopia server.
- On the
clients A and B, setup kopia to connect to
S. You can either use the GUI or the CLI, but I recommend sticking to one to keep things consistent. Note that after this initial setup, the clients should cache the credentials so you shouldn’t need to keep repeating this step. The clients should auto connect to it whenever it launches.
- On each of the clients, configure the scheduling and other policies (e.g., how many snapshots, compression, what directories to backup, etc.). Note that GUI has scheduling inbuilt as long as it is running in the background. By default the GUI minimizes to tray so you can launch it and ignore it as it will be out of your way. You can also have the GUI auto launch on startup to have this process mostly automated to ensure that the clients will not accidentally miss out on critical backups. The launch on startup I believe can be accessed via the context menu from the tray. You will need to configure each client independently. All the configuration can be done using the GUI.
- If you are using the CLI, you are responsible for scheduling the commands yourself, maybe via
systemd timers/cron jobs/windows scheduler, etc. The CLI, as dimejo explained, is one-shot and doesn’t do scheduling.
Thank you stpr, that clears things up. I think what I failed to explain is these
clients A and B, while not kopia servers, are servers as in headless linux machines that I interact with over CLI only. The use case you explained I have working with KopiaUI for my desktop/laptop machines. Here I am trying to ascertain if I can use kopia on
A and B, server machines, to configure backups while still proxying the repository to a third server which is a kopia server. My previous experience with KopiaUI and what you wrote here
Note that GUI has scheduling inbuilt as long as it is running in the background.
makes me think there is. But I’m in the middle of reorganizing these machines and I’ve torn down my test kopia setup so I’ll have to poke around at this again later.
Then you make cron running your snapshots. On my servers, I am doing it usually this way:
- at boot time a service sets up the Kopia connection parameters
- cron runs my snapshots
Note, that the Kopia connection parameters themselves don’t cause a connection to the Kopia server, they only enable the Kopia cli client to get their bearings on how to connect to the server.