On 12.04.2012 23:59, vijay patel wrote:
>
> Hi Friends,
>
> I am using rsync to copy data from Production File Server to Disaster
> Recovery file server. I have 100Mbps link setup between these two servers.
> Folder structure is very deep. It is having path like
> /reports/folder1/date/folder
You can try to switch to faster filesystems (reiserfs/ext4/btrfs/zfs)
and enable metadata performance options and do other tuning steps
(dir_index, noatime) and upgrade disks and ram etc, but mostly, with a
frankly unrealistic business requirement like that, you have to either
tell business tha
On 04/12/2012 04:36:44 PM, vijay patel wrote:
>
> We are running Kernel 2.6.18-308.1.1.el5 which is latest in RHEL 5.8
> on both the server. I think i might have to explore option of using
> ext4.
Before you do anything you want to figure out why it
is slow so you can solve the real problem. vms
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
That is a bit old for ext4. You need 2.6.28 as the bare minimum but
there were a few early issues. I don't remember exactly when it
stabilized but I think it was in the low 2.6.30s. Your 2.6.18 is from
2006. (Yes, I know, RedHat has been patching i
We are running Kernel 2.6.18-308.1.1.el5 which is latest in RHEL 5.8 on both
the server. I think i might have to explore option of using ext4.
> Date: Thu, 12 Apr 2012 17:31:35 -0400
> From: k...@sanitarium.net
> To: rsync@lists.samba.org
> Subject: Re: Rsync takes long time to finish
>
> ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There was also a serious performance regression in 2.6.39.
On 04/12/12 17:29, Dan Stromberg wrote:
>
> I've heard lots of good suggestions already - another thing that
> I've not seen mentioned is, upgrading your kernel may help.
> Somewhere shortly
I've heard lots of good suggestions already - another thing that I've not
seen mentioned is, upgrading your kernel may help. Somewhere shortly
before kernel 3.0, pathname lookups got noticeably faster.
You could also try an alternative filesystem like xfs. It's supposed to be
pretty good at larg
On 04/12/2012 04:19:47 PM, Kevin Korb wrote:
> Yes, you have the feature in your filesystem. Good.
(Note that you will want to check the filesystems on
both ends.)
Karl
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
--
Please use reply-all f
yes both servers are having rsync 3.0.6.
> Date: Thu, 12 Apr 2012 17:19:47 -0400
> From: k...@sanitarium.net
> To: rsync@lists.samba.org
> Subject: Re: Rsync takes long time to finish
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yes, you have the feature in your filesystem. Good. I
Chris Arnold schrieb:
Are you saying the current way we are doing it does NOT support "incremental"
backups after the first full backup?
Oh, the rsync itself will do incremental, however if the filesystem
below is going over VPN it won't work fast. rsync's design expects local
and fast files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, you have the feature in your filesystem. Good. If it is ext3
then converting it to ext4 would still help assuming your distro
supports it.
You are using rsync over ssh. This is my preference as well for
security reasons. Using rsyncd would be
I am getting following thing in 'tune2fs -l' :
Filesystem features: has_journal resize_inode dir_index filetype
needs_recovery sparse_super large_file
Does this mean it is set?
One more thing i am not using rsync as daemon (Because i am confused with its
usage at the moment), will it ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
And make sure both systems are running rsync v3. It indexes in
parallel to the copying.
On 04/12/12 16:59, Karl O. Pinc wrote:
> On 04/12/2012 03:28:18 PM, vijay patel wrote:
>>
>> Thanks friends. We are using Redhat Linux 5.8 on Production and
>>
On 04/12/2012 03:28:18 PM, vijay patel wrote:
>
> Thanks friends. We are using Redhat Linux 5.8 on Production and
> Disaster Recovery side. By drilling down we have found out it is
> taking lot of time to check what has changed while data tranfer is
> very fast. As i mentioned data in these fol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I would say that it uses a method that has been obsolete for years to
reinforce a model that has been obsolete for a decade :P
(it defaults to cp -al instead of --link-dest and reinforces the
outdated organization model based on tape rotation)
On 04/
At 03:47 PM 4/12/2012, Kevin Korb wrote:
The third is retaining the differences between the current backup and
the previous backups. This allows you to restore from previous
backups without consuming tons of extra space. Rsync accomplishes
this with the --link-dest feature. It is not dependen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It depends on what you mean by "incremental backups".
There are 3 things involved with rsync and backups...
The first is rsync's ability to not not backup the same file twice
unless it has changed. This will work with any method as long as you
sync
Are you saying the current way we are doing it does NOT support "incremental"
backups after the first full backup?
One of the NAS devices is a readynas duo rnd2100. In the backup section of the
gui, it does say backup:remote::rsync but when i select that and fill in the
info and click test conne
Thanks friends. We are using Redhat Linux 5.8 on Production and Disaster
Recovery side. By drilling down we have found out it is taking lot of time to
check what has changed while data tranfer is very fast. As i mentioned data in
these folders is very less (hardly 40GB) and whenever new file
Brian K. White schrieb:
On 4/12/2012 3:36 PM, Joachim Otahal (privat) wrote:
it has not been mentioned: nohup !
Yes it was.
You are right, found your post now.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba
On 4/12/2012 3:36 PM, Joachim Otahal (privat) wrote:
it has not been mentioned: nohup !
Yes it was.
--
bkw
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http:/
it has not been mentioned: nohup !
screen is a bit complicated if you never used it. It only makes sense if
you want to check back later and see life what is going on.
at or cron would be my last restort.
nohup would be my choice
nohup (you command and options) &
Example:
x@x:~> nohup ls -la &
The first clause should read "does not parallelize".
-Original Message-
From: rsync-boun...@lists.samba.org [mailto:rsync-boun...@lists.samba.org] On
Behalf Of Stier, Matthew
Sent: Thursday, April 12, 2012 3:07 PM
To: Kevin Korb; rsync@lists.samba.org
Subject: RE: Rsync takes long time t
This is like mounting the remote drive via samba and then do a sync,
this is like doing a normal copy job without the deltra transfer
benefits of rsync.
If at all possible you should run an rsync daemon on the NAS box and
then run the rsync command on the other side of the VPN. rsync uses port
And, although rsync does parallelize, nothing stops you from running multiple
instances of rsync.
I had to transfer files from system A to system B, and being limited by the
processing power of a single thread of rsync, I drilled down one level, and ran
rsync's against each the first level file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Several suggestions...
Add a lockfile to your cron job so it doesn't run two instances at the
same time and you don't have to predict the run time.
Make sure you are running rsync version 3+ on both systems. It has
significant performance benefits o
Hi Friends,
I am using rsync to copy data from Production File Server to Disaster Recovery
file server. I have 100Mbps link setup between these two servers. Folder
structure is very deep. It is having path like
/reports/folder1/date/folder2/file.tx, where we have 1600 directories like
'folde
On 4/12/2012 12:32 PM, Chris Arnold wrote:
On Apr 11, 2012, at 10:48 PM, "Brian K. White" wrote:
Now just run the rsync command. no nohup, no&.
Just so completely understand, it should be:
rsync --options x no nohup no&
Or am I completely wrong?
No I was saying that if you were using s
On Apr 11, 2012, at 10:48 PM, "Brian K. White" wrote:
> Now just run the rsync command. no nohup, no &.
Just so completely understand, it should be:
rsync --options x no nohup no &
Or am I completely wrong?
Btw, Brian K. White, that looks familiar. You a member of the opensuse or
postfix l
On Thursday 12 April 2012 11:20:54 joop g wrote:
(I forgot to include my rsync commands)
> mount -t ntfs-3g -o locale=nl_NL.iso-8859-1,silent
> /dev/disk/by-id/usb-DiskA \ /mnt/tmp ||
> mount -t ntfs-3g -o locale=nl_NL.iso-9959-1,silent
> /dev/disk/by-id/usb-DiskB \ /mnt/tmp ||
> mount -t ntfs-3g
Hello, *
I am setting up a backup on a Linux system with Windows XP workstations. The
backup goes to three alternating usb drives, each of which is NTFS formatted.
The disks should be virtually identical but they do not seem to be.
First, my mount command is this (I edited a bit for brevity)
m
31 matches
Mail list logo
