From: adfas asd <chimera_god@yahoo.com>
To: linux-raid@vger.kernel.org
Subject: Re: Is My Data DESTROYED?!
Date: Mon, 26 Oct 2009 05:22:03 -0700 (PDT) [thread overview]
Message-ID: <835545.17492.qm@web38807.mail.mud.yahoo.com> (raw)
In-Reply-To: <4AE4F36A.9070504@redhat.com>
Thanks Doug, this was very helpful. I had seen the checksum option, but sometimes something doesn't register as useful unless there is independent confirmation.
And understand that I am not 'shooting down' anything to be obstinate; I am testing and probing for the -best- solution and systems, and hoping something good pops out. Some of the sensitive will take offense, but I suggest that all benefit when we get substantive responses such as yours.
I had tried afio and cpio in the past, but frankly could not figure it out to use. Seems like a good concept. Maybe it's been made more accessible by now, or maybe I'm not as dumb. BTW, I am a real estate developer, not a coder.
--- On Sun, 10/25/09, Doug Ledford <dledford@redhat.com> wrote:
> That being said, you can in fact have what you want by
> simply telling
> rsync to use file MD5 sums to determine which files need
> synced from the
> master to the slave instead of file size/date data.
> That's right, you
> can, by passing a simple flag to rsync, cause it to read
> each and every
> single file, generate an md5sum of the file, and use that
> to determine
> if the file needs backed up or if the file already on the
> backup machine
> is identical. In other words, this mode of operation
> is *superior* to
> the raid solution your comparing it against.
>
> But, this all raises a very simple point that I'm surprised
> someone else
> hasn't brought up yet. If you had merely looked at
> the rsync man page,
> or even just the rsync help information on the command
> line, you would
> have seen this for yourself. So, might I suggest that
> before you spend
> to much time trying to shoot down what is probably a very
> workable
> solution for you, that you actually *LOOK INTO* that
> solution instead of
> letting prejudice and ignorance drive your decision.
>
> > And what does it take to set up this emailed report?
>
> Run rsync in a cron job and *don't* redirect rsync's output
> to /dev/null
> and you will automatically get these emails (assuming that
> you already
> redirect emails to root to your own personal email
> account).
>
> > And what backup system/script was used?
>
> Rsync is it's own backup system when used as such, nothing
> else is
> needed. You essentially create a cron job to run
> rsync, and your entire
> script consists of simply getting the rsync command fine
> tuned to your
> particular application. Here's an example of an rsync
> cron job I use to
> mirror Fedora repos to my local server:
>
> [root@firewall ~]# more /etc/cron.daily/sync_fedora
> #!/bin/bash
> #
> # Only used on rawhide
>
> cd /srv/Fedora/rawhide
> [ -f .syncing ] && exit 0 || touch .syncing
> for arch in x86_64 i386 ppc; do
> rsync -acq --delete
> rsync://fedora.secsup.org/fedora/linux/development/$arch/os/
> $arch
> if [ $arch = "x86_64" ]; then
> ln
> $arch/Packages/*.noarch.rpm i386/Packages >/dev/null
> 2>&1
> ln
> $arch/Packages/*.noarch.rpm ppc/Packages >/dev/null
> 2>&1
> ln
> $arch/Packages/*.i[356]86.rpm i386/Packages >/dev/null
> 2>&1
> fi
> done
> rm .syncing
>
> [root@firewall ~]#
>
> Note that because I use the -q flag to rsync, I don't get
> nightly emails
> unless something goes wrong.
>
> >
> >> It's also a simple matter to run a
> >> compare between the two systems. One can
> compare
> >> every single file, or for
> >> brevity one can easily compare only the most
> recently
> >> created files.
> >
> > Yes yes, but how?
>
> RTFM please.
>
> >>> Also I've noticed rsync mentioned several
> times.
> >> This seems to have
> >>> facilities for incremental backups, but I've
> also read
> >> that it is non-
> >>> secure over networks and that we should use
> scp
> >> instead.
> >>
> >> It's secure if you use ssh
> with
> >> passphraseless keys as its transfer
> >> mechanism. Why are you worried about it if
> this is a
> >> home LAN, though? How
> >> is someone gong to sniff your LAN, especially the
> link
> >> between the two
> >> hosts?
> >
> > I am told that use of OpenSSH vastly limits the
> bandwidth of the connection, due to encryption
> overhead. Backups could cost more than 24 hours a day,
> and/or cut into CPU cycles needed for
> commercial-flagging. So I'm looking for secure
> alternatives.
> >
> > And no I'm not too concerned with someone sniffing my
> LAN, but if practical security can be had I always use
> it. For example I set up reverse SSH tunnels for
> MythTV, MySQL, and Squid. No it's not mandatory, and
> it is difficult, but it is best-practice.
>
> Might I suggest a little less "so I'm told" and a little
> more "so I
> tried this out and this is what I got...". In this
> particular case, if
> you are worried about the poor authentication of rsync
> without ssh, but
> concerned with the overhead of encrypting all the data
> transferred, then
> why not just set up ssh so that it does encryptionless data
> transfer
> between these two machines? Then you get the benefit
> of the improved
> authentication strength of ssh, but not the overhead of the
> encryption
> on the link. But, in truth, as long as you aren't
> running an atom CPU
> or something like that, you should have more than enough
> CPU horsepower
> to encrypt a gigabit link's worth of data transfer.
> And especially if
> you choose to use the md5sum comparisons in rsync, your
> machines will be
> far busier just reading the data from disk and doing
> md5sums of the
> entire array, so worrying about the CPU overhead of the
> encryption is
> kinda silly.
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG KeyID:
> CFBFF194
> http://people.redhat.com/dledford
>
> Infiniband specific RPMs available at
> http://people.redhat.com/dledford/Infiniband
>
>
next prev parent reply other threads:[~2009-10-26 12:22 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <70ed7c3e0910221840o795a61b9u77774725386868e2@mail.gmail.com>
2009-10-23 2:04 ` Is My Data DESTROYED?! adfas asd
2009-10-23 20:32 ` Billy Crook
2009-10-23 20:46 ` Christian Pernegger
2009-10-23 20:57 ` Mattias Wadenstein
2009-10-23 21:44 ` Billy Crook
2009-10-23 22:00 ` adfas asd
2009-10-23 22:46 ` Billy Crook
2009-10-23 22:49 ` adfas asd
2009-10-23 23:54 ` berk walker
2009-10-24 0:13 ` berk walker
2009-10-25 0:22 ` Leslie Rhorer
2009-10-23 21:55 ` adfas asd
2009-10-23 22:36 ` Guy Watkins
2009-10-23 23:05 ` Bill Davidsen
2009-10-23 23:20 ` adfas asd
2009-10-23 23:20 ` NeilBrown
2009-10-23 23:25 ` Ben DJ
2009-10-24 3:39 ` Bill Davidsen
2009-10-24 12:01 ` adfas asd
2009-10-24 14:59 ` Christopher Chen
2009-10-25 1:52 ` Leslie Rhorer
2009-10-25 2:03 ` Christopher Chen
2009-10-25 2:30 ` Leslie Rhorer
2009-10-25 5:26 ` Thomas Fjellstrom
2009-10-25 5:41 ` Guy Watkins
2009-10-25 6:21 ` Eyal Lebedinsky
2009-10-25 22:55 ` Guy Watkins
2009-10-26 1:36 ` Leslie Rhorer
2009-10-26 2:40 ` Guy Watkins
2009-10-26 7:32 ` Eyal Lebedinsky
2009-10-26 18:14 ` Thomas Fjellstrom
2009-10-26 23:14 ` John Robinson
2009-10-27 2:50 ` Leslie Rhorer
2009-10-27 3:15 ` Thomas Fjellstrom
2009-10-27 14:37 ` adfas asd
2009-11-02 22:53 ` NiftyFedora Mitch
2009-10-26 23:21 ` Leslie Rhorer
2009-10-25 6:15 ` Christopher Chen
2009-10-25 13:06 ` Leslie Rhorer
2009-10-25 12:46 ` adfas asd
2009-10-25 13:38 ` Gabor Gombas
2009-10-25 15:47 ` adfas asd
2009-10-25 18:12 ` Christopher Chen
2009-10-25 18:33 ` Gabor Gombas
2009-10-25 14:16 ` Leslie Rhorer
2009-10-25 16:06 ` adfas asd
2009-10-25 16:58 ` Thomas Fjellstrom
2009-10-26 0:55 ` Doug Ledford
2009-10-26 12:22 ` adfas asd [this message]
2009-10-25 16:49 ` Thomas Fjellstrom
2009-10-25 1:28 ` Leslie Rhorer
2009-10-23 23:49 ` berk walker
2009-10-25 1:36 ` Leslie Rhorer
2009-10-25 1:50 ` Christopher Chen
2009-10-25 2:20 ` Leslie Rhorer
2009-10-27 21:08 adfas asd
2009-10-27 21:11 ` John Robinson
2009-10-27 21:22 ` adfas asd
2009-10-27 21:31 ` Christian Pernegger
2009-10-27 21:56 ` adfas asd
2009-10-28 3:14 ` Guy Watkins
[not found] <1256656849.15137.126.camel@poledra.romunt.nl>
2009-10-27 20:31 ` adfas asd
2009-10-27 20:39 ` Ryan Wagoner
2009-10-27 21:00 ` Christian Pernegger
2009-10-28 0:39 ` Leslie Rhorer
2009-10-28 2:57 ` Rudy Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2009-10-26 12:56 adfas asd
2009-10-26 18:21 ` Thomas Fjellstrom
2009-10-27 14:32 ` adfas asd
2009-10-27 14:36 ` Gabor Gombas
2009-10-27 14:40 ` adfas asd
2009-10-27 18:22 ` Ryan Wagoner
2009-10-28 9:50 ` Lars Schimmer
2009-10-27 20:45 ` Bill Davidsen
2009-10-27 20:53 ` adfas asd
2009-10-27 21:00 ` Ryan Wagoner
2009-10-27 21:05 ` adfas asd
[not found] <70ed7c3e0910221912h70b33ca0m3df9eedd9a54c459@mail.gmail.com>
2009-10-23 2:18 ` adfas asd
2009-10-23 2:43 ` Majed B.
2009-10-23 2:59 ` adfas asd
2009-10-23 3:14 ` Majed B.
2009-10-23 19:24 ` adfas asd
2009-10-23 23:07 ` NeilBrown
2009-10-23 23:25 ` adfas asd
2009-10-23 23:39 ` Majed B.
2009-10-24 4:37 ` NeilBrown
2009-10-25 0:54 ` Leslie Rhorer
2009-10-23 22:37 ` Bill Davidsen
2009-10-23 22:41 ` adfas asd
2009-10-24 9:02 ` Luca Berra
2009-10-23 2:30 ` adfas asd
2009-10-23 22:28 ` Bill Davidsen
2009-10-26 15:38 ` Darius S. Naqvi
2009-10-23 1:36 adfas asd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=835545.17492.qm@web38807.mail.mud.yahoo.com \
--to=chimera_god@yahoo.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.