Not really. Think about it this way: everything about UrBackup is client/server architecture. When you loose a client - recover it from a server. If you loose both a client and a server (like in single PC scenario) - recover the server first before you can do anything else - this is obvious.
But to recover a server, it is not enough to simply dump a bunch of data from other server on it because UrBackup does a lot more than simply one way sync of your files. It can work with multiple clients, each of which with separate settings. You have multiple users, quite a lot of serverâs settings. It has this concept of data versioning, file deduplication across clients and so on. It needs to keep track of a lot of things and is quite busy doing all that magic. So it uses configuration files and databases of its own. If you want to restore a server, you need to restore these files and only then it can make sense of whatever you pointed it to. Maybe think about it like metadata about everything that is in the storage location.
I suspect weâre talking past each other, at least a bit.
What Iâm saying is that any UrBackup Server, when itâs running, is creating every last bit of that metadata in its backup repository (taken as a whole). And if ANY UrBackup Server is pointed to look at a full backup repository, regardless of whether itâs one it created, or otherwise, it should have full access to all information to do a restore out of that repository without the end user having to dig into the repository by hand.
I can, when using things like Restic, EaseUS, Paragon, etc. (which are not client-server, but the repository idea is the same) I can point the recovery side to ANY backup that was ever made on ANY machine and it is capable of restoring from it to the machine Iâm currently sitting on. You can even do this with Microsoftâs File History feature; it can restore backups taken in one place on to an entirely different box. Mind you, I am talking file backups here, not system images. But it can even be done for system images (it just doesnât necessarily make any sense to try to take a system image from one box and try to restore it, lock, stock, and barrel, to another).
This is exactly how it works. For whatever reason you just donât want to accept that what you described as a âfull backup repositoryâ is more than just clientâs files. Give it that âfull backup repositoryâ and it works like you expected.
it can restore backups taken in one place on to an entirely different box
So does UrBackup, tried and tested on multiple occasions. I was also going through restoring UrBackup Server or using âfull backup repositoryâ from one server on a new one. Works like a charm.
I have no idea, whatsoever, why you believe I donât understand what the full backup repository is in the same way you do, because I do.
I said, earlier, that it was my presumption, based on evidence presented, that this was what the OP had in his D:\BackupMain folder, and if you look at post #9 that looks like precisely whatâs in that folder. All the components for a single client managed by a single server appear to be there. That being the case, the instructions I gave should work if that data is not corrupt.
I know very well that any backup repository is not just a copied stash of files. Thereâs an entire support structure involved thatâs created by the backup software that created it, and that the recovery side depends upon if recovery is needed
Iâm sure you do understand, but you are still ignoring what I said earlier and what is clearly stated in the docs - this âfull repositoryâ consists of files from storage location and C:\Program Files\UrBackupServer\urbackup or /var/urbackup/.
All the components for a single client managed by a single server appear to be there. That being the case, the instructions I gave should work if that data is not corrupt.
Correct. And it would work if he copied D:\BackupMain\urbackup\ to Program Files.
Personally, I think thatâs a big, big flaw in UrBackup. End users (and weâre all end-users of UrBackup in this context) should not be having to copy ANYTHING under the Program Files hierarchy. The software should be âsmart enoughâ to recognize what the situation is when pointed to a ânon-native repositoryâ and take care of that stuff without any intervention on the part of the user.
Also, and I say this with true gratitude, it would have been a lot clearer if you had just laid this out this way earlier, particularly given what the OP has posted.
Itâs crystal clear, while the documentation is, shall we say, quite opaque for the uninitiated and can even be challenging for the initiated.
Personally, I think thatâs a big, big flaw in UrBackup.
I strongly disagree, for me it is a good feature. And Iâm tempted to say, Iâm under impression you have a bit of a history of demanding something works just like anything else you know.
it would have been a lot clearer if you had just laid this out this way earlier, particularly given what the OP has posted.
Well if anyone knew how it will unfold then⌠it would not happen.
It is clear that you have spent a LOT of time and effort trying to help him out, it just didnât work out on that occasion. I hope it will not discourage you from helping someone else in the future. Keep up the good work with screenshots and all that.
Different strokes for different folks. I was a sysadmin in a Unix environment for years (now years ago) and have been in the Windows world for decades.
Having end users need to dig in to those folders is, in my opinion, always a mistake. Itâs a simple matter to make the software situationally aware and to do that kind of âdirty workâ for the user so that nothing can be accidentally screwed up.
And when it comes to backup and recovery software, I do want a great deal of consistency across products in basic functionality. I make no secret of that, and I think itâs a good thing.
Itâs becoming more and more clear to me that UrBackup, for all its fabulous features (and there are many), is not aimed at âyour typical userâ and that even those of us who have years of experience in the field can find ourselves confused by how UrBackup names things and that itâs documentation is largely without examples, including screenshots.
It does not lend itself to ease of use for anyone who is not familiar with it, even if theyâre already intimately familiar with one or more other backup and recovery suites. And thatâs a shame, and something that would be well worth remedying.
When I saw that my files got overwritten I quickly tried to download a files recovery program to see if I could get anything back and also tried to put my dead drive in to see if it would work for at least 1 more day like it did when I backed it up. Well it didnât work and it felt like it was making more clicking sounds than before. The file recover program sadly couldnât get anything back. I also tried to use nirsoft shadowcopyview in the last 30 minutes but couldnât find a VSS snapshot of D. I just want to go ahead and thank both of you for taking all this time and effort to help me, even if this wasnât the intended result I still have all my files on a drive and just canât restore it.
It shows me my download, photos, program data etc. I can access all my games and things like that which is fine. The only thing Iâm confused about is now all my save files for my games are gone, I donât even know how. Other than that I have everything, or at least almost everything from my old drive before it died
If I had the time, Iâd definitely consider it, but I really donât. My plate is full with being on the technology tutor network for our stateâs department for the blind and vision-impaired, along with other stuff thatâs going on as well.
But one of the things that would really improve the documentation is a much more generous inclusion of screenshots when discussing all sorts of functionality. A picture really is often worth several thousand words.
My guess, if itâs steam f ex, there are two on windows (I think) roaming and local (or somehing like that). one is for the steam synced saves, and the other is your local saves, should not matter witch one you fill tbh, steam would just ask you witch version you would want to use.
If its not on steam, the exact same concept applies.
Check the credentials (ownership I think they call it on windows) for the files. They could become whack if you just copied from âlatestâ.
But this has more or less nothing to do with urbackup.
What happened to you you is the exact reason I have 2 things implemented.
I backup my urbackup server settings folder so I have MULTIPLE versions of the database files.
I store my urbackup server database files on a different partition from the one I run the program from. Because of that, if my os completely fails and I have to reinstall, I ALLWAYS have my files backed up on another drive easy to get going once everything is reinstalled.
I have my servers on linux so its easy for me to just symlink the whole /var/urbackup folder (I dont remember where they reside) so if I reinstall, I just delete the folder the reinstalled urbackup created and reapply the symlink and start the server.
I saw one of you argue that âits bad design or urbackupâ or something like that, sure maybe. But EVEN if that is the case, ALWAYS make backups of your settings files when reinstalling a program, I thought that was basic computer knowledge.
Also, a backup is never really backup until you have restored from it.
Double redundancy is almost a must imho, otherwise, why spend all the space on backups that âmight workâ. In my case, I have double servers AND use btrfs so store selected snapshots from my main backup folder.
Anyway, glad you got it to work and good luck with your gaming OP.
