Trying to migrate storage, Server 2.2.4 + 2012 R2


#1

Trying to move my UrBackup set to a larger 5TB disk array.
I created the migrate_storage_to file, and entered new folder name:

Q:\UrBackup Storage

Then I created that folder in Q:
Started UrBackup service, but log is full of repeated errors for all existing backups:

2017-10-05 15:49:08: ERROR: Error creating folder “Q:\UrBackup Storage\\Ironhide\171004-0202_incomplete.hashes”. The filename, directory name, or volume label syntax is incorrect. (code: 123)
2017-10-05 15:49:08: ERROR: Copying backup id 6065 path 171004-0202 of client “Ironhide” failed.

Not sure what I’m doing wrong …
I thought maybe at first the double \ was because I had entered “Q:\UrBackup Storage” with the trailing backslash, but a second attempt without it still failed.

I should also mention that it did create all the client computer subfolders and all their backup folders (with “incomplete” appended). It also created the inode_db with 1TB inode_db.lmdb file.


#2

No ideas, anyone? I’ve got a few TB of backups and it would be quite a pain to lose it all.


#3

OK Just reporting back as to what the problem ended up being - UrBackup does not like having a space in the path.

I renamed the destination folder from “Q:\UrBackup Storage” to just “Q:\UrBackup” and now it’s running fine.

@uroni - may just want to update the admin manual to mention that.


#4

So, it finished but is now starting again with the backups that had completed in the days during this migration.

I got quite a few failures on older backups as it progressed:

10/28/17 08:39 INFO Copying backup id 275 path 160516-1834 of client “Server”…
10/28/17 08:47 ERROR Copying backup id 275 path 160516-1834 of client “Server” failed.

When I look in the server logs, this is what it says:

2017-10-28 08:47:42: ERROR: Directory pool path target “P:\UrBackup Storage\Server.directory_pool\uO\uO53jJ1bRM14643383701257983828” does not exist
2017-10-28 08:47:42: ERROR: Copying backup id 275 path 160516-1834 of client “Server” failed.

Is this something I need to be concerned about? It happens on most of the clients, and generally the oldest backups.


#5

I had basically the exact same experience. Not sure if it’s all good or not. Was nice of the inode file to take up 25% of my total disk space. :expressionless:


#6

Well, this has turned into a complete disaster. None of the backups are working, and are stuck in various states of progress.
I’ve tried repair_database, cleanup_database, defrag_database, and nothing is working.
I am close to the point that I just need to force a full re-upload of ~5TB of data.
Where is @uroni when you need him! lol


#7

OK so the disk usage it absolutely ridiculous now. I’ve lost half my backups’ history and I’m still nearly out of space, after migrating to a drive that’s twice as large.

I deleted the inode file, as I don’t believe it is needed after the migration is “finished.”

And now I see this in my UrBackup storage folder…


#8

I renamed the inode_db and it created a new one. Still want to know what it’s for, documentation for this is terrible,


closed #9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.