I’ve been using URbackup to backup all the files from a linux server. That means everything from the / path, system binaries, libs, everything.
The linux server in question has BTRFS as a filesystem.
I would like to completely restore to a previous version of the entire OS. So I’ve booted the server into rescue mode. I’ve installed the urbackup client. However if I try to list the backups, by using “urbackupclientctl browse” then it says “error getting file backups”.
How can I get the client to behave so that I can properly restore?
Restoring from the linux client in cmdline is helish,
If you re connected to multiple backup server, it s even more annoying , because you can t chose which one to use.
If you study the commanline help , you eventually find all parameters that you need but the backup id.
To get the backup id you need to try to download a file from the gui, and in the url, look up the backup id. You ll also see that the backup path is the relative path.
If you have the option : 1000x simpler.
Set a variable in the client conf file, i think it s “allow-restore”. Then restart the client
That will show a “restore” button on the server, you click on it , it will restore very fast (sometimes it asks for confirmations, sometimes not).
However now I’ve run into another problem, if I try to restore from the web interface, I eventually get an error that the client has no file access tokens and that I should run a backup first. !?!?!?
Im running a incremental backup now. But this seems kind of ridiculous. Why is a freshly installed client incapable of browsing backups and restoring? Even if you install the Urbackupclient for the specific client from the webinterface. The problem with the file access tokens still exists.
I’m beginning to think I need to reconsider relying on URbackup for my backup needs.
It might be fine an dandy if you just need to restore a single file, but if you want to backup an entire server it’s probably best to rely on other methods, e.g. btrfs send / rdiff-backup, etc…
It’s a shame, because my favorite feature about URbackup is that I can set up a new client in no time. And I have a central place where I can see which backups have failed and so on.
So I’ve booted into rescue mode. The client’s harddrive ist mounted under /mnt/Debian/.
I’m trying to restore the entire OS.
If download the urbackupclient for that specific client from the Urbackup webpanel, it’s not sufficient. It will complain about missing file tokens when trying to browse backups.
Ok, so I start an incremental backup. After this finishes I can browse backups. But I can only see the backup that I just performed. I can’t see the previous ones via “urbackupclientctl browse”.
I shutdown the urbackupclientbackend service. I delete all the files in /usr/local/var/urbackup and I restore them from the mounted client that I’m trying to recover. In this case those files and access tokens where located under /mnt/Debian/usr/local/var/urbackup.
I had to do another incremental backup for some reason. Only now am I able to browse the backups from the commandline and select a specific one to restore.
This all seems like a serious design flaw. No access to backups unless you make a backup first?
And then you still need to recover your old file tokens first?
Also the whole way how urbackup clients and server authenticate each other seems needlessly cryptic and complicated. If for some reason it doesn’t work out of the box, then It’s a huge PITA to try and getting working again.
The only thing the client should ever need to authenticate itself is the key that is displayed in the web interface for that particular client. Might help to have an option for the cli client to re-authenticate with a provided key that the user enters. Then all the tokens get flushed and regenerated.
Did you try to specify a different client name from the commandline using urbackupclientctl using -v?
if you try to restore via commandline, what s the exact command you are using?