Le 4 août 2013 à 17:25, K S Braunsdorf a écrit :
> In message , AZ 9901 writes:
>> Due to --link-dest, I have a huge read activity at the beginning of each
>> backup, and huge hard links creation activity.
>> I also plan to have several backups at the same time, coming from dozens
>> of servers.
>
Due to --link-dest, I have a huge read activity at the beginning of each backup,
and huge hard links creation activity.
I also plan to have several backups at the same time, coming from dozens of
servers.
So I think that I need to pay attention to Rsync daemon storage.
Thanks !
Ben
Le 3 août 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It probably isn't going to make much of a difference. The bottleneck
will be in the networking.
On 08/03/13 15:46, AZ 9901 wrote:
> Let's say that I would like to try using --link-dest :-)
>
> What about RAID specifications (type, number of disks, c
Let's say that I would like to try using --link-dest :-)
What about RAID specifications (type, number of disks, chunk size...)
on receiver side ?
For example, should I use 256K chunks, same size as the IOs
made by the Rsync daemon / receiver ?
Thank you very much !
Ben
Le 12 juil. 2013 à 19:2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
With millions of files I suggest ditching --link-dest and using ZFS
with subvolume snapshots. You will have nothing but pain trying to
deal with many millions of links.
On 07/12/13 12:48, AZ 9901 wrote:
> Hello,
>
> I am going to use Rsync over mill
Hello,
I am going to use Rsync over millions of files, with --link-dest option.
So huge read activity at the beginning of each backup, and huge hard links
creation activity.
Of course I will use a RAID array on receiver side, dedicated to Rsync.
Do you have any recommandation over RAID type, nu
