v8 Unable to restore file into ext4 partition(linux)

[kgajda]

Case ID: 01400113

I found a critial bug (Veeam Backup 8 Standard version is 8.0.0.2084), that break restoration of single file into linux ext4 partition.

I will describe the problem:

I have two near-the-same linux VM (ubuntu LTS 14.03 based). Both have 500GB linux partitions.
Differences:
1) serwerplikow (affected) - have lot of files (large too) on their partitons
2) poczta (not affected) - have less, but small files.

When I'm trying to recover single file into "poczta" - no problem, but when I'm trying to recover any single file ("MAX.txt" in this case, but could be any), there is an error:

12.01.2016 20:08:43 Instant FLR engine is ready
12.01.2016 20:09:32 Error Failed to process [/home/000_no_backup_000/it-crowd/MAX.txt] Error: ChannelError: ConnectionReset
12.01.2016 20:09:32 Restored folders: 0

I included logs from veeam linux agent (Agent.FLR.Target.log_cli.log) and some logs from veeam8 backup, that I found errors relating to this failed file restoration job.

Link below:
http://stelmet.com/www-upload/veeam8-error1.zip

PS: Something is wrong with enumeration files, linux agent give response like that (below) that are files, that lives in folder, where restoration took place:

Code: Select all

[12.01.2016 20:09:13] <19> Info     Reading "veeam_soap.tar" from directory "C:\Program Files\Veeam\Backup and Replication\Backup\"
[12.01.2016 20:09:14] <19> Info     Answer to installation: :
[12.01.2016 20:09:17] <16> Info                   [AP] (Client) state: closed
[12.01.2016 20:09:17] <19> Info     FSItem [/media/sdb1/000_no_backup_000/it-crowd/Protokół przekazania sprzetu.doc] supportability info not found. Treating as supported.
[12.01.2016 20:09:17] <16> Info     [Ssh] Connection::Closed

[12.01.2016 20:09:17] <14> Info     [Ssh] Connection::Closed
[12.01.2016 20:09:17] <19> Info     FSItem [/media/sdb1/000_no_backup_000/it-crowd/ipo (192.168.0.100) — skrót.lnk] supportability info not found. Treating as supported.
[12.01.2016 20:09:17] <14> Info     [Ssh] Connection::Closed

[Dima P.]

Hi kgajda,

Thanks for opening the case - lets await for the support’s team investigation results. Meanwhile, can you clarify was file level recover appliance configured in identical way for both types of restores? Also, were you overwriting or keeping the said file while performing the ‘failed’ restore.

[alanbolte]

I believe there is a known issue with non-Latin characters like ó and ł, try copying the files or restoring them via FTP instead of trying to restore directly.

[kgajda]

Hi kgajda,

Thanks for opening the case - lets await for the support’s team investigation results. Meanwhile, can you clarify was file level recover appliance configured in identical way for both types of restores? Also, were you overwriting or keeping the said file while performing the ‘failed’ restore.

About recover appliance - do You means credentials and the way of access to this linux VM? It is configured in the same way (user account that is able to do sudo without password)

It doesn't mater, if recovery was done with overwriting or keeping original file.

[kgajda]

I believe there is a known issue with non-Latin characters like ó and ł, try copying the files or restoring them via FTP instead of trying to restore directly.

I'm using UTF8 filenames. There should not be a problem with the non-Latin charcters in names. Linux and windows hadle this well. Do You mean, that Veeam doesn't handle file names well? If so, then how it perform, when it is installed on environment with china chars/cyrlic as default?

[veremin]

To confirm whether problem is related to specific symbols try to follow the suggestions provided by Alan - restore files via FTP and see whether the issue re-occurs. Thanks.

[kgajda]

I checked the option "Enable FTP server on appliance (advanced).

I can access and recover this file manually via FTP (works), but I want to find a solution to recovery directly into filesystem (using Veeam GUI), because it should work.

Support team asked me to install VBR9 in trial version and perform recovery. I want to try, but i have questions:
1) Can I install VBR9 int the same machine, which is VBR8 and they will coexists without conflict?
2) If no, so i will upgrade my VBR8 into VBR9, but i was concern about CBT. Do I need to reset it in vmware environment?

[PTide]

1) Can I install VBR9 int the same machine, which is VBR8 and they will coexists without conflict?

No, v8 will be automatically upgraded to v9 in this case.

2) If no, so i will upgrade my VBR8 into VBR9, but i was concern about CBT. Do I need to reset it in vmware environment?

Please check this thread for details on that matter.

Another option would be to install a separate v9 server inside a spare VM, configure it as a default repo and copy a backup file from your primary repo to it. After that you can try restoring some files with a help of your staging VBR9 without affecting your production backup infrastructure.

Thank you.

[kgajda]

Upgrade to VBR9 is on the go. In the end I will report, how single file restoration into linux ext4 is performed.

[kgajda]

Good news guys VBR 9.0.0.902 have solved this bug!! Many thanks!!!