I needed to restore a documents folder for an employee here at work, so I went on the webserver and downloaded the folder - which came as a zip as I expected. Once I double clicked on it, Windows was claiming the zip was invalid. If I tried right-click / extract it was claiming that I needed to add files to the zip before I could extract. The UrBackup server is Running linux. The client is Windows 7. The web interface downloads ~480MB (the zip file is like 478MB) - I don’t know if that’s everything or not since I can’t open the zip.
Any tips? I don’t want to SAMBA export any shares, what should I look at in terms of server logs that might hint at the problem? UrBackup server is version 2.0.30
ps - I’m also seeing a lot of errors similar to:
2016-07-29 08:12:28: ERROR: Error replaying symlink journal: Could create link at “/media/storage/urbackup/ins-cos-1/160720-0848/Users/Default” to “/media/storage/urbackup/ins-cos-1/.directory_pool/yd/ydtBmtW7cv14690302381440242021”
Not just that one item, my debug log has a lot of these types of entries
Yeah, that’s gonna be the fun part - this user had to be moved to a different workstation - I was able to restore her desktop folder (zip worked fine), but just not the documents I may have to randomly try other folders until I can find a smaller one…
Ok, I’ve located the issue, it’s definitely server side, but not sure how a permanent fix could be made.
Here’s what I did:
I downloaded the “broken” zip to another computer that had more robust archive extraction tools. I was able to extract the archive and see what files were and weren’t compressed. The last file it compressed was:
motto.docx
This was a normal docx file with no issues
The next file was/is the link file that Microsoft generates for backward compatibility for My Music (linking to c:\users<USERNAME>\Music
The official link that is backed up is:
lrwxrwxrwx 1 urbackup urbackup 33 Jul 28 18:50 My Music -> …/…/…/Users/kima/Music
This is where it all goes wrong. It and the next two links (My Pictures and My Videos) are symbolic links based on the path with its existence on Windows. The path does not exist in that structure when it’s backed up on Linux.
When I tried:
ls …/…/…/Users
The result was:
ls: cannot access …/…/…/Users: No such file or directory
I went ahead and removed those three folders from that one users Documents folder and went to try to download the zip again, and it downloaded a 1.29Gig zip file.
So, with how UrBackup handles the symbolic links within windows appears to cause the zip functionality at the web interface download to break the instant one of those broken files show up.
So, can I add an exclusion like:
;\Documents\My/ Music;\Documents\My/ Videos;*\Documents\My/ Pictures
Will that work? It doesn’t solve my problem of having to go through all of my existing backup to remove those folders, but would it stop new backups from saving those symbolic link files?
Those links should be perfectly fine. You can test that by cd into the link. You should restore folders containing symlinks with the client. I’ll have a look at zipfiles + symlinks.
I’m not sure how much more I can explain this - the links are wrong. They are not disabled, they are just wrong. They are backed up sym links from a windows machine that the link references a location that doesn’t exist on a linux machine - the path doesn’t exist.
Here - a screenshot is worth a thousand words in this case I think:
When you try to CD to it - since it’s a broken link, it doesn’t work. See:
root@backserv:/media/storage/urbackup/ins-cos-1/current/Users/kima/Documents# cd My\ Music
-su: cd: My Music: No such file or directory
There are plenty of functional links, and following paths works fine for links that exist properly. This isn’t a matter of symlinks not being followed - it’s a matter of symlinks specific to windows that are copied as is over to linux where the paths don’t match up, causing broken links, which causes the zip functionality to break - this has nothing to do with symlinks within apache (which follow symlinks is enabled)
technically the correct is kim.atkinson, I was concealing her name in the posts before for privacy reasons, but there was no way to do that with the screenshot to explain the situation…
And I understand it’s not copied verbatim - plus a symbolic link to C:… wouldn’t make much sense in Linux anyway. But that link is a relative path, not a full path anyway.
/media/storage/urbackup/ins-cos-1/current/Users/kima/Documents/My Music points to ../../../Users/Music which is /media/storage/urbackup/ins-cos-1/current/Users/kima/Music.
Does /media/storage/urbackup/ins-cos-1/current/Users/kima/Music exist? And if not, why not?
and I can access it normally if I change into it…
root@backserv:/media/storage/urbackup/ins-cos-1/current/Users/kim.atkinson# ls -l | grep Mu
drwxr-x— 2 urbackup urbackup 4096 Jul 29 07:05 Music
root@backserv:/media/storage/urbackup/ins-cos-1/current/Users/kim.atkinson#
It’s an empty folder (we don’t back up music, videos or pictures (except for a few specific work stations) to conserve space)
In theory that link should work, but I’m not seeing a good reason why it doesn’t.
Sorry if I seem grumpy - I know you’re offering good information, it’s been a crappy Friday so far and I’m a bit more snippy than I should be.
Update note: I had some ideas, none of which panned out. I don’t quite understand why if I do: ls …/…/…/Users/kim.atkinson/Music I get no such file or directory, but if I do a cd …/…/…/Users/kim.atkinson/Music it works fine. Especially since if I do a ls …/…/…/ I get:
I’m sure this is all tied to where the problem lies, but I can’t really explain any better how it all works due to the way all of the linking takes place for incremental / full backups.
Ok, that’s just weird. Especially that cd ../../../Users/kim.atkinson/Music works but cd My\ Music doesn’t. Is one of the folders in the path Users/kim.atkinson/Music or Users/kim.atkinson/Documents a directory symlink? If yes that must be the reason…
Ok, I originally figured I’d have to wait until I got back to my office to check, but conveniently - I had posted the picture of the ins-cos-1/current/kim.atkinson folder. Looks like, as it was an incremental backup, Documents is a symbolic link to another location. So if that’s causing the break, wouldn’t that mean that it could affect any linked folder at any time if during incremental or de-dup detection on full that the way the links are assembled it could cause a broken sym link to follow?
So, I guess the ultimate question - is there something I can do to fix this, or is it something in a future patch of urbackup? Also curious - could some of this be related to those errors I referenced earlier?
Well, let me know if you need any other information that might help you - at least I know I can get to the files I need - just might need to dig a little
I may have to randomly try other folders until I can find a smaller one…
