Been a while since I was on here, as my UrBackup instance has been happily chugging away without issues…
Need to spin up a new VM as the Linux distro has gone EOL and somehow I missed the memo, so also missed the cutover date…
Have currently got UrBackup configured to use a second VHD for the backup target, so am hoping that I can spin up a new VM instance with the latest(?) version of UrBackup installed, then point it to use the existing repository so I don’t lose the backups…
Does anyone know how this is done, as it isn’t obvious in the documentation…?
The actual datastore is locked to the database, there are also hard links (the UNC you used in the WebGUI to the datastore) are hard coded in the database.
The ONLY way to not loose the data is to take the database to the new server AND keep the UNC the same (which should be possible as sounds like you can just connect the datastore virtual disk to the new PC).
So if it were me i would install the new OS, new UrBackup, then restore the old database in to that new UrBackup, then with the current disk that should work. You can upgrade UrBackup in place by just installing… (well we can on the QNAP install)
@OnlyMe Can you keep us all updated how it goes trying to do this. I think (myself included) we are all looking for a good “official” method (including steps) to migrate a UrBackup instance to a new platform. I haven’t tried this yet and am hoping to migration process isn’t too cumbersome.
When you say hardlinks. Do you mean: If you used "X:" as the target drive, it will look for the exact path of "X:" and not accept any other drive letter? If yes, that’s not too bad as long as the target drive is exactly the same and uses the same drive, letter. Is this correct?
Also, what steps would you recommend in importing the “database” to the new UrBackup instance?
I am currently running a Windows Server and would want to know how to replace the default database. I’m assuming the UrBackup Server service should be shutdown while the import is happening. Is it really that simple?
I want to apologize, kind of got impulsive on my last post. Been wanting a good solid answer on how to migrate or just transfer to a new platform in case the current one goes bust.
I was doing reading on this, i cant remember where i saw it, but the line used in Settings > Server > Backup storage path is used in the database directly… it was about moving the datastore to a new drive, the result was that link HAS to be identical for the database to work as there are hard coded use of that UNC.
I am sure i put a feature request in for a BACKUP / RESTORE for the main data system to allow migration. I also believe a “migration” assistant would be nice if you do need to move the datastore OR have a button to “copy from A to B” type button to allow you to MOVE the datastore to a new location that would also update the database OR better still a “click this to point to the new datastore” which then reads that and the database to then “fix” and connect them together again.
Some code is already in place for this as there is a script that will check the store and database to confirm all the data is ok, however it generally will just delete anything in the database if it cant find it, resulting in many PCs vanishing.
We have seen an odd thing with the PC NAME, if it has a space and you add a new one, it will make the one with a space vanish. So “A PC” name works until you add “A-PC”, then “A PC” vanishes from the system and you only have “A-PC” let… we just had this issue, the only fix was to delete all PCs that had a space in the name and any PCs that were similar then re-add them once th enighly clean up happened. Checking the real file store it did appear the folder structure was removed for “both” the effected names.
The issue ive seen, when we tried to move it on a NAS there were over 2.1 million files, which took DAYS to move (over 10Tb). Even then we lost the HASH data so have to run a full file backup on every PC.
When I first decided to deploy UrBackup, I made a specific decision to uniquely identify each “PC Name”. So each name is unique to the point that this collision cannot occur, but that doesn’t solve the problem, it’s just a workaround. Glad I thought of that before deploying!
What the heck happened to the hash data, why was it suddenly gone or did you never have a chance to investigate it?
No idea… i supposed it would depend how the HASH is created, all i know is i saw 10’000 errors in the incremental backup, doing a FULL backup resolved it, it appears the hash was trashed… all the data was copied, however we are using QNAP NAS and not a PC / Linux install hosting the server… the full backup got around the issue. We only store 5-12 weeks of data, so loosing it really isnt an issue for us. But it does raise an interesting question.
Was replying to @GRIFFCOMM first reply, but it didn’t include it when posting this…
Sorry for late response, spent the last couple of days sorting out Hyper-V cluster issues for a custy when they let their repository fill up…
Not sure if the “hard coded” bit is something that is literally “unchangeable” as have moved the store in a previous instance, when moving it from the OS to a different drive…
Was already considering just attaching the existing VHD to the new instance (yet to be spun up) but would expect there would be issues if the new instance doesn’t have the rest of the config [and history] to know about the clients…
For me, this is currently only covering a handful of [live] systems, so I could just bin the whole thing off and start again from scratch…but would rather have the history available…
Also, to cover the “X:” comments by @ProfoundIT in here, my scenario is on a Linux server, so it’s more of “/mnt” pointing to “/dev/sdb” for me…from memory…though know you’re on Windows from your post…
Glad I thought of that before deploying!