Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian User (http://www.linux-archive.org/debian-user/)
-   -   CIFS and data integrity (http://www.linux-archive.org/debian-user/688672-cifs-data-integrity.html)

Mark Fletcher 07-29-2012 04:50 PM

CIFS and data integrity
 
Ahoy the list!

I use a Buffalo 4TB NAS using RAID which I mount from my Debian Wheezy
AMD64 running on a self-built Intel Core i7 920-based machine.

I want to be able to read and write the NAS from the Linux machine
with minimum fuss. I also run a virtual Win7 guest on my Linux host,
and want to be able to access the NAS from there also. I explicitly
mount the NAS from the Linux host when I want it, and just access it
from the Windows guest using Windows Explorer by referring to the NAS
by its network name. I wouldn't _object_ to being able to auto-mount
the NAS on boot of the host, as long as doing so doesn't cause untold
hassle if the NAS is not available.

One purpose of having the NAS is a place to store backups as
protection against disk crashes on the Linux host, VM disasters, etc.

Currently I mount the NAS on my Linux box using the following command
as root. I am wondering if there is something wrong with this command
as I will explain in a moment:

mount -t cifs <network path of NAS>/share -o guest /mnt/nas

After having done this, I can read data on the nas as any user by
referring to /mnt/nas. It seems that to write I have to be root, which
is inconvenient and something I'd rather avoid but not a disaster.

The issue is this: It seems that data I write there after mounting is
not maintaining 100% fidelity. Here's an example:

Dump a mysql database I have on my Linux host:

mysqldump yahdahyahdahyahdah > /opt/recovery/mysql20120725.sql

Then bzip2 the puppy:

cd /opt/recovery
bzip2 mysql20120725.sql

Test the correctness of the archive
bzip2 -t mysql20120725.sql.bz2

(One time I also extracted it all again to a different directory and
diffed with the original to make sure it was good and could be
extracted back to the original)

This produces a demonstrably-correct compressed archive of my db
backup, about 150MB in size.

Now copy that to the NAS:

cp mysql20120725.sql.bz2 /mnt/nas/dbbackup

(directory /dbbackup already existed on the NAS)

That copy operation results in a file on the NAS that is identical in
size to the one I copied.

cd /mnt/nas/dbbackup

bzip2 -t mysql20120725.sql.bz2

... results in a failed test saying the archive is corrupted. Fair
enough, I thought, perhaps bzip2 doesn't like operating over the
network. So I then copied the backup file back to a different location
on the host, bzip2 -t 'd it there, and got the same error.

It looks like what got stored on the NAS is not exactly what was
originally on the host. This is a huge problem for me as it means I
can't rely on backups dumped on that device. Is there something wrong
with the way I am mounting the NAS that is leading to this?

Thanks


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAH6Gj5G6yQ9F_m3624S--rr67A2oZwPdfuJr0y+r34x4PfKvVQ@mail.gmail.com">http ://lists.debian.org/CAH6Gj5G6yQ9F_m3624S--rr67A2oZwPdfuJr0y+r34x4PfKvVQ@mail.gmail.com

Gary Dale 07-29-2012 05:23 PM

CIFS and data integrity
 
On 29/07/12 12:50 PM, Mark Fletcher wrote:

Ahoy the list!

I use a Buffalo 4TB NAS using RAID which I mount from my Debian Wheezy
AMD64 running on a self-built Intel Core i7 920-based machine.

I want to be able to read and write the NAS from the Linux machine
with minimum fuss. I also run a virtual Win7 guest on my Linux host,
and want to be able to access the NAS from there also. I explicitly
mount the NAS from the Linux host when I want it, and just access it
from the Windows guest using Windows Explorer by referring to the NAS
by its network name. I wouldn't _object_ to being able to auto-mount
the NAS on boot of the host, as long as doing so doesn't cause untold
hassle if the NAS is not available.

One purpose of having the NAS is a place to store backups as
protection against disk crashes on the Linux host, VM disasters, etc.

Currently I mount the NAS on my Linux box using the following command
as root. I am wondering if there is something wrong with this command
as I will explain in a moment:

mount -t cifs<network path of NAS>/share -o guest /mnt/nas

After having done this, I can read data on the nas as any user by
referring to /mnt/nas. It seems that to write I have to be root, which
is inconvenient and something I'd rather avoid but not a disaster.

The issue is this: It seems that data I write there after mounting is
not maintaining 100% fidelity. Here's an example:

Dump a mysql database I have on my Linux host:

mysqldump yahdahyahdahyahdah> /opt/recovery/mysql20120725.sql

Then bzip2 the puppy:

cd /opt/recovery
bzip2 mysql20120725.sql

Test the correctness of the archive
bzip2 -t mysql20120725.sql.bz2

(One time I also extracted it all again to a different directory and
diffed with the original to make sure it was good and could be
extracted back to the original)

This produces a demonstrably-correct compressed archive of my db
backup, about 150MB in size.

Now copy that to the NAS:

cp mysql20120725.sql.bz2 /mnt/nas/dbbackup

(directory /dbbackup already existed on the NAS)

That copy operation results in a file on the NAS that is identical in
size to the one I copied.

cd /mnt/nas/dbbackup

bzip2 -t mysql20120725.sql.bz2

... results in a failed test saying the archive is corrupted. Fair
enough, I thought, perhaps bzip2 doesn't like operating over the
network. So I then copied the backup file back to a different location
on the host, bzip2 -t 'd it there, and got the same error.

It looks like what got stored on the NAS is not exactly what was
originally on the host. This is a huge problem for me as it means I
can't rely on backups dumped on that device. Is there something wrong
with the way I am mounting the NAS that is leading to this?

Thanks

Is this repeatable? Have you tried doing a file cmp to verify the copy
worked? I do this as a matter of course to ensure a good backup.


Normally I prefer to use rsync across a network. Rsync will only copy
the parts that have changed.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 5015717E.2090805@rogers.com">http://lists.debian.org/5015717E.2090805@rogers.com


All times are GMT. The time now is 04:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.