Joe <joe <at> jretrading.com> writes: > > On Mon, 30 Jul 2012 01:50:14 +0900 > Mark Fletcher <mark27q1 <at> gmail.com> wrote: > > > > > 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? > > > > Probably. I'd guess it is a matter of permissions. If you create the > archive elsewhere, copy it to the NAS, copy it back again, presumably > there is no difficulty. I also use a Buffalo NAS, but my backups are > created on my server, then copied. It is possible that if the > compression and expansion is done on the NAS, that a temp file involved > may not have the correct permissions to write, or more likely, amend. > But is your backup not running under cron as root? >
I put the exact commands I was executing in my original post. There's no job involved, I am typing these commands at the command prompt. I'll bring a job into it once it works reliably. If you read my original post, you can see I create the archive on the host's local disk, test it to make sure it is good, and then copy it to the NAS in a separate operation. I use the cp command to do the copy. I'm inclined to rule out a bug in the cp command, which leaves something about the way the data is being transferred to my NAS. Hence my concern about whether my mount command (again, see details in my original post) was correct. And yes, to answer someone else's question, this is reproducible, reliably, every time. The copy on the NAS is always the same length as the copy on the host's local disk, but diff says they are two different binary files and the one on the NAS cannot be extracted. Thanks Mark > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20120730t085028-...@post.gmane.org
