Problem on backup files - Message "File too large"

[LacieHasser]

Hello folks,

using a 5big vs2 running the original OS and thanks of FVDW-SL-console 18 and some very helpful posts here I have access to the shares after frontbutton blinking blue, but I stuck w. problem "File too large".

Loading Kernel KIRKWOOD-171-standalone, assemble Raid for md4 - everything's fine, I can see all the shares, most of them contains movies greater than 2 GB.

Using a 1TB-USB-disk formatted ext3, mounted in /mnt/usb for backup w. command 'cp' - result: Some of the files were copied, but not the rest w. message "cp: can't open '/mnt/md4/shares/3/movie-xyz.mp4': File too large"

The same w. expanded glibc-and-tools-archive.tar

Working w.dd on a single file has the same result, but dd-64 on >3,5 GB is ok, but it's troublesome to do that for all files!

Building a small ftp-server w. busybox tcpsvd -vE 192.168.2.252 21 busybox ftpd -w /mnt/md4/shares works fine also w. files < 2 GB, greater same as above.

How can I handle them?

Tried to use vsftpd instead, but it doesn't run...

Any ideas?

BTW a question about iSCSI-files: Where are they located? Can't find them...

[fvdw]

Tried to use vsftpd instead, but it doesn't run...

:scratch
Did you try to run it after er uploading mini glibc and tools?

Also read this topic http://plugout.net/viewtopic.php?f=26&t=2508&start=20#p22816

[LacieHasser]

Thx for answering and submitting of the link.

Yes, I've downloaded the mini glibc & tools.tar to use the vsftpd, but I didn't know about the "&" after the command vsftpd.

Without it doesn't start, with

Code: Select all

vsftpd &

it works perfekt also w. big files!

But can you explain, why cp doesn't work? I've read in other post about this problem that the standalone-kernel was compiled for support of large files. What about busybox1 ?

Code: Select all

busybox1 cp

Does it help?

I would still prefer direct copying to a USB-disk because it's faster, most of the files were up to 4 GB, some of them 5 to 8 GB.

[fvdw]

Need to check but we had to minize the standalone kernel in size to be able to load it in ram. Therefore the binaries are minimized as well. Its a 32 bits limitation issue causing the problem to use cp to copy big files. I need to check if busybox was compiled to suport bigfiles but apparently not. Recompile busybox could solve it but will increase size of the standalone kernel and as result may not fit in ram anymore.Furthermore copying to usb using cp will not be faster I expect compared with using vsftp, this because the cpu must handle read and write when using usb. And when you use an usb stick it wil for sure be not faster because of slow writing speed of usb stick.

[LacieHasser]

Hi fvdw,

I can follow your explanation of the limitation - that's too bad...
Maybe it's possible to make rsync workable instead of/in addition to cp?
And "Sorry" for not describing exactly the term USB-disk:
I'am using a SSD w. Adapter to USB like doing 1:1-copies of harddisks, so speed is not limited of a slow Stick.

[Jocko]

Hi

on such platforms, rsync is never faster then cp command with a first synchronisation (in fact it is slower :whistle )

@fvdw
yes busybox1 does not have support for large files (and it is why you compiled vsftpd later to fix this issue)

[LacieHasser]

Hello again,

after backing up most of the files (the rest were rsync-backups) I've done some research about location and recovering of iSCSI-files in the original OS to answer my question above by myself:
They can be found in /md4/images in a single file named '1' (2 or 3 depends of your use) as big as your LUN-target was.
It's a block device, so you can download it via vsftpd or copy it by

Code: Select all

dd-64 if=/mnt/md4/images/1 of=/mnt/usb/lun1.img bs=1M

The mounting process in /md2/EDMINI/var/log/unicorn.log shows "losetup /dev/loop1 u /media/internal_1/images/1".

Then start a Linux-Live-System of your choice (I prefer Gparted) and mount it in the same format as you've formatted them (Linux ext2/3/4) or NTFS in my case, but it doesn't work with the img-file directly under Win10 or Linux.
Why? Because the offset! So it's missing the start byte!

These website is a good choice for understanding: http://infotinks.com/mount-luns-with-partitions-using-losetup-and-kpartx/

Now there are several options to make the img-file readable, let me describe my simple 5-step-way using Gparted:

1. Show the partition table of the virtual disk (here around 100 GB in MBR mode, for GPT: sgdisk -p):

Code: Select all

user@debian:~$ sudo fdisk -lu /mnt/usb/lun1.img
Disk /mnt/usb/lun1.img: 109 GiB, 117037858816 bytes, 228589568 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00014fff

Device             Boot Start       End   Sectors  Size Id Type
/mnt/usb/lun1.img1         32 228589567 228589536  109G  7 HPFS/NTFS/exFAT
user@debian:~$

Result => Starts at sector 32 => Offset-Calculation: 32 * 512 = 16384 // as variable $((32*512))

2. Create mountpoints (in may case the img is on a SSD-disk attached via USB)

Code: Select all

sudo mkdir /mnt/usb /mnt/lun
sudo mount /dev/sda1 /mnt/usb


3. Mount read-only it for NTFS:

Code: Select all

sudo mount -t ntfs -o ro,offset=16384 /mnt/usb/lun1.img /mnt/lun

4. E voila! To show all the files for backup:

Code: Select all

ls /mnt/lun

5. Finish after backup:

Code: Select all

sudo umount /mnt/lun

#####

Now a final question:
What do you think is the best way to restore the original OS in an other way as LaCie suggest in their manual which results in "recovered_ShareName_..."?

Thanks in advance,

[LacieHasser]

Exactly one year ago after recovering my 15-TB-5big2 w. original OS it's time for a short feedback:
All shares were on board under /Share/Recovery as promised by LaCie, after re-arranging the box is running very well over the last 365 days.

Only the iSCSI-Files (lun's) are not accessable after recovering, you have to delete them and formatting those device again (and copy the data back if you want so).

!	Conclusion & warning: iSCSI is _not_ a good way for data-storage on a LaCie-device!