-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
server initiated restore with regex not working on burp 2.0.48 #501
Comments
One additional note:
|
Hello, |
Hello, I have tried with 34 and 31 in server initiated restore. first test:
Searching with same regex looks like it founds the file (also works if use -a r):
second test works if server initiated restore with include = (path):
|
Hello, In your '-a l' output above, it is not showing any found files. It is only outputting the names of the backups that it searched, but not showing any results. I would make a shorter/simpler regex to try to match, like this: It will be most useful to look directly in the manifest of backups 31 and 34 to debug this. Please use 'zless' to look at the manifests, and search for the entry for the file in 31 and 34, if the entries exist. Thank you. |
Issue #333 suggests adding a message when a regex matches no files - if I had implemented that, it would have helped your '-a l' a little bit. |
Hello Graham, Thanks a lot for your responses. I have been testing more with two servers and same files, and now I suspect the issue is something that could be related to fs performance. First testing in two servers (server1 production, server2 test) server1 doesn't find the file with -r regex (finds now with simpler regex after doing some changes in fs mount options) server1 is having much more disk usage and different filesystem (xfs) Load is higher normally but limited to 4 childrens in both. For all I can see, I suspect that I need to use something like ext4 for burp and no other fs like I'm using now xfs? The main reason why I think it's something related to fs or performance is about find command: SERVER2 (test) find command:
SERVER1 find command:
Then reading more about xfs, I have noticed it: And found some different results:
After changing it I have seen that in SERVER1 simpler regex works:
But not the complex regex, that works on SERVER2. (test). SERVER2 (test):
SERVER2Using idle server only with one client (test server):
server test log:
SERVER1:(test previous)
Server log:
Analyzing manifest in both:server 1:
server2 test:
Main differences between server1 and SERVER2:server1:Uses NAS through iscsi with xfs.
server2:Has only 1 client ConclusionI think it is not a burp issue, something with fs that could affect burp. Kind regards, |
I think that it is most likely not the filesystem. If you are using a network filesystem, it will make things slower. It's not going to affect whether regex matches things in the manifest or not. I observe that one manifest has a lowercase 'c' as the drive letter, and the other has an uppercase 'C' as the drive letter. |
Hello Graham, Thanks for your response. You are completely right, I haven't noticed it when doing manual test with -a l -r regex (but was only mistake in manual testing -a l). In resume: there are 2 problems with "Server initiated restore and regex":
I'm pasting all the details that I have been checking just to have clear info. SERVER1Regex in SERVER1 now works with C in uppercase.
SERVER2The server initiated restore curiously works
Trying to reproduce the error in SERVER2 (test)Also with xfs on SERVER2 now. I have changed the include to uppercase C in client for SERVER2.
The regex shows the last backup as the unique with C uppercase:
Unfortunately it didn't reproduce the error.
I have rebuit SERVER1 but didn't change anything. Trying to reproduce the problem 2 in SERVER2 (Reproduced)Finally I have reproduced the problem when I deleted all the backups and started again to BURP2:
I have tried also with c lowercase but got same result. Also tried to reduce the incexc parameters, now using:
It's done in a nested incexc files:
Recovering from reproduced problem.Simplified configuration with incexc recovers from the reproduced problem:
Found the root cause of the issueAfter big amount of combinations, I found how to reproduce the problem. If I add some include=/path/non/in/backup The regex works but the server initiated restore doesn't. Let me show in real example: Backup 9 Adding only:
In incexc/profile_win6x Restore works, also regex:
Adding include=c:/Notes to
regex works but server initiated restore doesn't:
Seems that the bug is with regex from server initiated restore when incexc configuration doesn't equals all folders in backup. Also I have checked that same behaviour happens when using nested include_glob.
Now I'm thinking how to workaround it, maybe I need to exclude those dirs that are not part of the backup on all the clients for now. Kind regards |
Workaround fix done in my burp2_server role: CoffeeITWorks/ansible_burp2_server@32f1791 |
I haven't reviewed all the data that you posted yet. |
no issues! Anyway if someone reports this kind of issues with server initiated restore El mar., 8 nov. 2016 a las 8:26, grke (notifications@github.com) escribió:
|
Hello, I have tried to read and follow what the issue that you are working around is, but I don't understand. I think I need: These things need to be as small as possible. The absolute minimum amount of config that is needed for the demonstration. I will run (a) on a client with no previous backups. Are you able to send me (a) and (b)? |
For windows tests I have done it: I have incexc folder with: https://github.com/CoffeeITWorks/ansible_burp2_server/tree/master/files/incexc Then I add a clienta with this info:
Do a server initiated restore with the profile_win6x as it is. https://github.com/CoffeeITWorks/ansible_burp2_server/blob/master/files/incexc/profile_win6x Then to replicate the issue just add one include line with path non existing on the client (on backup):
attach requires extension, so here is the file also: For Linux I need to test same. Kind regards, |
Do you do a backup, then restore, then add the line to the config, then backup, then restore? |
Previous tests were: First do backup Now as you asked for these steps I have added to the tests: Now I have do backup (with line previously added) Then remove the line Note: regex expression used in lasts tests is simple, like c:/path/testfile |
I managed to reproduce it. Hopefully I can fix it soon. |
Now fixed in master. |
Awesome!
Thanks!
El mar., 13 dic. 2016 a las 8:49, grke (<notifications@github.com>)
escribió:
Now fixed in master.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#501 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEQPn-MJPK3kSlPB8Mh-HZoxbJvdmSiTks5rHoY3gaJpZM4KgQFU>
.
--
Pablo.
|
Hello Graham,
I think I found an issue when testing restore from server initiated, same happens on original cliente and in a different client using restore_client.
Restore that works:
from command line.
Restore that doesn't works:
from server initiated restore:
From client on server:
Could be something wrong with parameters used to compile on server? Or could be a bug?
Parameters used to compile:
from: https://github.com/CoffeeITWorks/ansible_burp2_server/blob/master/tasks/build-burp.yml
Hope this could help in some way.
Thanks for all what is done and all the efforts you are doing every day!
Pablo.
The text was updated successfully, but these errors were encountered: