-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Filer.backup does not work as expected #2084
Comments
@Stranger10110 Check the filer.replicate parameter
|
@kmlebedev My settings are: [sink.local] I don't understand, what's wrong with them? I've tried to do a backup on Linux VM with 192.168.0.244 ip address parameter there (IP of a host machine), but it doesn't work either. Why have you set such port 18080? Filer is on 8888, so it should be 18888, isn't it? |
Thanks for the details! Could you please add |
Here it is: win filer.backup log 2.txt I've changed folder structure (by uploading 2 new folders ("base_1" and "base_2") and changing on file) since last launch. There are some changes (it downloaded these 2 new folders and changed file, also made more "date" folders), but it's still does not work as expected. I think it ignores "is_incremental = false" as well. (I don't see missing files in v=4 logs either) |
I added some fix for the is_incremental. Please use this to run https://github.com/chrislusf/seaweedfs/releases/dev |
Yes, it's not incremental now, but still missing some of the files. When I've run it first time with a new version files were same as before. But I've deleted them, run again, cancel it in the middle of the process (with CTRL+C) and every time now it's got "stuck" again and miss more of the files. I think it downloads to the time when I hit CTRL+C and no more, but I'm not 100% sure. Maybe a bug with restarting backup from the last point of progress? |
I fixed some obvious problems with the local sink, and updated the dev release. Please help to check again. If still problem, please attach filer.backup logs. |
Unfortunately, almost no changes for me. First try : downloaded those 2 "new" folders only (in folder test2; there is no 'Meta_test2' folder anymore too). Second try: uploaded a new file (verthash.dat), retried to make a backup, result - those 2 folders and new file only. So it downloads files from some point of time and nothing before that, as it literally says it in the log: It needs a way to make it start from the start, I think, like '-startFromBeginning" parameter maybe |
See "weed filer.backup -h" |
what is the |
Same as before. It was also used for WSL 2 |
it showed some "D:/tests/..." folder in the log. Not sure how that happened. |
can you use |
PS D:\Seaweed> .\weed shell |
ok. not too many files. Can you run this |
Here it is: meta.txt P.S.: I do just some tests right now, so I don't care about these files, if you want me to do something with them to investigate bugs, just let me know |
The metadata logs showed the source filer had an upload to |
share your python code that caused the problem? I want to see how to prevent the bug in the future. |
I think I've already fixed that bug. |
Thanks! Added a fix for windows. |
I am trying to test a backup to local disk (both on Windows and Linux) of files that are stored with Filer (MySQL), but it doesn't seem to work properly - it just doesn't copy all the files, only specific files and folders, not even full sizes. Maybe it's just getting stuck for whatever reason?
I also tried to change the directory on Filer in replication.toml, but it does no effect.
It also makes two folders of different dates, but I've configured it to "is_incremental = false".
System Setup
Weed cluster is started with Docker compose (Docker.zip; it contains filer.toml as well).
OS version:
Weed version:
FIler.backup start command: .\weed.exe filer.backup -filerProxy
Replication.toml: replication(.toml).txt
Expected behavior
A full copy of files stored with Filer on a local disk.
Screenshots
Filer
Windows backup
Linux backup
Same picture as on Windows.
Additional context
File.backup output from Windows: win filer.backup log.txt.
File.backup output from Linux: linux filer.backup log.txt.
The text was updated successfully, but these errors were encountered: