FLR Multi-OS via FTP no files with dots

[br_sc]

Version 6.0.0.158
If I use the Multi-OS FLR appliance and connect via FTP to the appliance, directory names (and i guess also file names) that start with a "dot" charachter (UNIX "hidden") are not visible. I am trying to restore files from a Windows dynamic disk (so no Windows FLR) that contains directories that start with a dot charachter.
Is this a known limitation of the Multi-OS FLR appliance that can be fixed?
FTP is the prefered way to "restore" the files, since the copy operations using the Multi-OS wizard are so godawfully slow (compared to FTP which is really fast).

[foggy]

Michael, do you see this behavior in different FTP clients?

[br_sc]

I tried the microsoft ftp.exe client, the FTP client integrated into "Total Commander" (www.ghisler.com) and "Filezilla". All show the same behaviour.

[foggy]

Quick research by our QC showed that this is actually an issue with the appliance. As a workaround you can try to use direct links to the files (something like ftp://appliance/folder/.file), if this makes sense to you. Thanks for pointing that out!

[tsightler]

My memory is that the appliance is built on Busybox, and the built in busybox FTP server doesn't have the ability to display hidden files.

The easiest workaround is to use SCP or SFTP instead of FTP. The IFLR appliance listens for SSH and the root password is docemented at http://www.veeam.com/KB1447 although you should note that with V6 the hostname is not necessarily the name of the Veeam server but rather the hostname of the proxy that is assigned as the PowerNFS server for the repository hold the backup files being used for the IFLR.

I use either standard Linux SCP/SFTP command line tools, or WinSCP for Windows machines. It's not quite as fast as FTP due to the overhead of compression, but still very fast and very flexible and this method has no problem with directories/filenames with dots.

[tsightler]

Also, the KB article that provides the password information for the IFLR appliance states that the hostname will not be the FQDN but in at least some cases it is.

[foggy]

Valid workaround, thanks, Tom!

[tsightler]

It's not quite as fast as FTP due to the overhead of compression...

Obviously this should have been "It's not quite as fast as FTP due to the overhead of encryption.

Another nice option for Linux/Unix heads (or Windows heads with Cygwin) is to pull the files over SSH via tar, using a command like:

Code: Select all

ssh -n ivrhost 'tar zpcvf - SOURCEDIR' | tar zpxvf -

Or you can pipe them straight to a file if you just want a archive to send to someone for example with:

Code: Select all

ssh -n ivrhost 'tar zpcvf - SOURCEDIR' > DESTFILE.tar.gz

If you're really a Windows head you can also to the same think above with "plink" which is part of PuTTY:

Code: Select all

plink root@ivrhost 'tar zpcvf - SOURCEDIR' > c:\DESTFILE.tar.gz

The great thing about using tar is that it is very fast when pulling a large number of files since there's no per-file protocol overhead like there is with FTP and SCP, it's just one continuous, compressed data stream. If you've ever needed to restore a 1,000,000 file directory tree with Veeam, you will love this, and if you're transferring Linux to Linux, it preserves permissions as well.

[cby]

I'd go along with Tom on the tar front having had to copy 12,000,000+ files/directories recently. But instead of scp/sftp I use netcat (nc) in client/listener mode which is faster than scp. And with the addition of pv (pipe-view) in the command line you get transfer rate, time and percent done stats -- very useful.

[cby]

Just in case you want to transfer directory with huge number of files...

# On target box cd to the target parent directory

[cby@target_box]# nc -l PORT|tar ixf -

--------------------------------

# On source box cd to the source parent directory

[cby@source_box]# tar c source_directory |pv|nc target_box_IP target_box_PORT

Note: some versions of netcat syntax vary! Also the [-]w option is useful for closing down connection after transfer is complete.

[tsightler]

Pulling out some netcat skills...awesome!! I didn't realize that netcat was part of Busybox and already on the instant recovery VM, I'm sure that really is fast.

I had previously used a static build of rsync as well, this having the advantage that it would only transfer files that were changed/different. I even played around with simply attaching the disk that I wanted to restore to directly to the IVR appliance. That works pretty good as well.

[foggy]

A handful of workarounds! Most likely, this will be fixed in the next product update.