Some bytes are zeroed out in the middle of file in backup copy.
Paul Slootman-5 wrote
> On Mon 29 Apr 2013, Kevin Korb wrote:
>>
>> Simply put, if you have something that is screwing with your file data
>> without touching your time stamps then you have been infected with a
>> rootkit. You sho
On Mon 29 Apr 2013, Kevin Korb wrote:
>
> Simply put, if you have something that is screwing with your file data
> without touching your time stamps then you have been infected with a
> rootkit. You should be thanking rsync for not backing up your
As he's running QNX I don't expect he's infected
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rsync by default checksums the whole file from the source vs the whole
file on the target even if the whole file on the target is a
combination of stuff that was already on the target and some stuff
that had to be transferred.
The only time I have eve
If full file checksum is matched with source before writing into disc.
Does it point to disc corruption?
What rsync options can be used to debug this issue ?
Do I need to read the destination file again and match the checksum with
source.
Kevin Korb wrote
> -BEGIN PGP SIGNED MESSAGE-
> H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -a should take care of making sure rsync doesn't re-transfer things
that don't need it. -c will make sure rsync takes longer than just
re-copying everything would.
Rsync does do a checksum of the files it transfers without -c.
On 04/28/13 03:40, a
Database lock is taken on active before rsync is done so it is in freezed
state.
I have added checksum so that later full syncing is not done on further
rsync.
Does cheksum is verified before writing data to disc in destination?
Kevin Korb wrote
> -BEGIN PGP SIGNED MESSAGE-
> Hash:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In use databases can't be copied with rsync or any file based tool.
The database must be inactive to be copied. You didn't mention which
kind of database you are using but most have a function to freeze the
database for backups. I don't know if QNX h
ing it for reading/viewing.
regards
roland
>List: rsync
>Subject: Re: file corruption
>From: joop g
>Date: 2013-03-09 10:33:54
>Message-ID: 3286855.GThHFMr6je () n2k6
>[Download message RAW]
>
>You said, the diff concerned just one byte, right?
No they are some random files..
It's really weird that rsync over ssh seems to catch the corruption ,
with warning messages " failed verification -- update discarded
(will try again)". However rsync to remote daemon just corrupts files
without any warning. Is it possible that I need to specify
You said, the diff concerned just one byte, right?
Were the corrupted files all Microsoft Office files? I have seen this behaviour
once, and then it turned out to be the originals that had been changed in the
meantime. It seems that Microsoft knows how to change a file without altering
the modif
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ouch. That sounds scary.
The first time I had such a problem I discovered it while trying to
burn a 600+MB avi file to a CDR. I burned a CDR and the md5sum of the
avi file on the disc didn't match. So I burned another one and it
didn't match either
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/08/13 22:16, xiaolong mou wrote:
> Thanks. I suspected hardware issue as well. However I did a local
> rsync test at the USB drive side and NAS side with the same files.
> If there was a local hardware problem (RAM or USB hard drive driver
> etc
Thanks. I suspected hardware issue as well. However I did a local
rsync test at the USB drive side and NAS side with the same files. If
there was a local hardware problem (RAM or USB hard drive driver etc)
it should show up in this test, but everything was fine!
Could it be network driver somehow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have seen this behavior before. Twice.
Both times the cause was bad RAM on the target system. The bad RAM
was corrupting the files within the disk write cache so that rsync
believed it was writing the correct data but the disk was not getting
the
> but even this would not do anything to avoid sending a partially-written file
> that was not yet
> complete (if the data remained unchanged while rsync was reading it).
Good point.,
That's was what I was thinking. A post transfer stat() (md5, crc, etc)
on the source file to help those who are
On Mon, Sep 12, 2005 at 09:36:27AM -0600, Kevin Stussman wrote:
> if rsync does do a checksum after the file has been transferred, but
> the original file has been changed during transfer, wouldn't the final
> checksum then fail?
No, as you suspected, the checksum is for the data that rsync read f
We have DB consultants here that must have missed this piece
of info re: "inserted after the online redo log is successfully
archived". I'm not a Oracle expert, all I know is that rsync
sees a file that needs transferring (completed or not).
The bit about rsync behavior was just a suggestion for a
Stefan Nehlsen wrote:
On Mon, Sep 12, 2005 at 09:36:27AM -0600, Kevin Stussman wrote:
rsync will have a second try if this happens and I think it will warn.
This seems like a waste of resources to me. Why not query V$ARCHIVE_LOG?
From the manual:
This view displays archived log information
On Mon 12 Sep 2005, Stefan Nehlsen wrote:
> >
> > I'm going to have a look at that now :-/
>
> FIRST: I do not know if the corruption where really caused by rsync!
>
> I had made a copy of the corrupt tree and use it know to find out
> what kind of corruption ocurred.
>
> I knew that there wher
On Mon, 12 Sep 2005 08:41:17 -0700, Stefan Nehlsen <[EMAIL PROTECTED]> wrote:
-3126060 093f b647 71af 8d62 1159 fbd0 3e30 e36b
+3126060 093f b647 71af 9d62 1159 fbd0 3e30 e36b
Is it always the same bit position (0x1000 here)?
If so, might be faulty RAM...
You probably already know about memte
On Mon, Sep 12, 2005 at 09:36:27AM -0600, Kevin Stussman wrote:
> Thanks for the explanation.
>
> Since I have no way to know if Oracle has completed the file, I solved
> the problem by making the transfer process smarter and only deleting the
> file once it has been successfully loaded into the s
On Mon, Sep 12, 2005 at 03:04:50PM +0200, Stefan Nehlsen wrote:
>
> I'm going to have a look at that now :-/
FIRST: I do not know if the corruption where really caused by rsync!
I had made a copy of the corrupt tree and use it know to find out
what kind of corruption ocurred.
I knew that there
Thanks for the explanation.
Since I have no way to know if Oracle has completed the file, I solved
the problem by making the transfer process smarter and only deleting the
file once it has been successfully loaded into the secondary. This way
if the file was corrupted (i.e. sent before completed)
On Fri, Sep 09, 2005 at 12:06:50PM -0600, Kevin Stussman wrote:
> We are using rsync to transfer Oracle redo logs from one system to
> another over a WAN/VPN. The problem we are having is that 1 out of about
> 500 or so files sent is corrupted. The receiving Oracle server produces
> a message like
On Fri, Sep 09, 2005 at 12:06:50PM -0600, Kevin Stussman wrote:
> - Is there way to ensure that rsync checks the integrity of the
> transferred file when it is complete?
Rsync validates that all the data it writes out matches the checksum of
the data on the sending side. The only known way to cr
25 matches
Mail list logo
