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
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
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
it should be easy, rsync is avail
on nearly all existing OS-es (well, limited to those with network
capabilities).
Joachim
- Original Message -
From: Joachim Otahal (privat)j...@gmx.net
To: Chris Arnoldcarn...@electrichendrix.com
Cc: rsync@lists.samba.org
Sent: Thursday, April 12
I know from a lot of NAS boxes that they tend to use their internal
time to stamp files instead of the time given by a copy job.
The easiest way to test is to deliberately set the time off by a few
hours on the box you monted the stuff on, the NAS and netapp (or the
PS: Another (ugly) workaround: Use two linux boxes, place then both on
each side of the slow line. One side having the NAS mounted + running
rsync server, the other having the netapp mounted.
Then sync between those two linux boxes. Even if you have to use -c or
--ignore-times the full read
Stier, Matthew schrieb:
But the timestamp would not.
Be careful with that, I had cases where picture editors kept the
timestamps even if they did change the content. Only atime was changed,
mtime stayed. The affected users had the option selected in the program
(they thought of it as a
samba-b...@samba.org schrieb:
https://bugzilla.samba.org/show_bug.cgi?id=8566
--- Comment #9 from Stefan Nowakp@gmx.at 2012-03-24 14:45:18 UTC ---
mdutil -E /Volumes/Destination
Re-indexing the destination volume did not help either.
xattr -rl showed that all comment data is still there.
Matt Van Mater schrieb:
image1 size in bytes: 17,062,442,700
image2 size in bytes: 16,993,256,652
about 70 MB of change between a boot with a small program install.
That is realistic.
Matt Van Mater schrieb:
Alternate assessment - I ran a similar comparison against the two
image files using rdiff that comes with Ubuntu 10.04.4 LTS (shown up
as librsync 0.9.7) and have a significantly smaller delta file (closer
to what i expect).
Just plain luck. If ubuntu wrote the most
the delta to get smaller (at the
expense of longer computation time).
Matt
On Tue, Mar 20, 2012 at 3:41 PM, Joachim
Otahal (privat) j...@gmx.net wrote:
Matt Van
Mater schrieb:
Alternate
br...@aljex.com schrieb:
Not that I have any say but I agree on both counts.
That is, I think it's ok for the 4.2.0 source not to be provided by them now,
if they are not supplying the 4.2.0 binaries now, but at least at the time they
were providing 4.2.0 binaries under gpl, then at that time
. It will appear to do more
since it will actually re-delta xfer everything but in my experience
that is faster than --checksum almost all of the time.
On 03/02/12 02:07, Joachim Otahal (privat) wrote:
Kevin Korb schrieb:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
I am not much
Kevin Korb schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am not much of a programmer so I know I could never take over rsync
development but if I could boss such people around here are the new
directions I would take:
1. --itmize-changes is eliminated and becomes part of --verbose
Von:John Doe **@gmail.com
An: Joachim Otahal (privat) j...@gmx.net
Real name? No, it's not, obviously.
For some reason I couldn't post this on the rsync forum, where I found
your request. Would you, kindly, consider adding the link there?
On Wed, Feb 15, 2012 at 10:41 PM
are still right.
Jou
Joachim Otahal (privat) schrieb:
A bit late, but someone (anonymous) provided a link to download.
the md5 is correct, it matches the last sourceforge state. And the md5
and sha256 mentioned at https://www.itefix.no/i2/node/12862 - before
he gave up the project.
MD5
Mark Constable schrieb:
I've looking for a solution for this and no amount of googling has
come up with anything.
Is it possible to provide a static listing on a server, say every
24 hours, that a standard end-user rsync can pull and use?
I have a lot of files to provide and the idea of every
Joachim Otahal (privat) schrieb:
When it is OK to let the users have an 24h old filelist, is it at the
same time OK if the user gets only up to 24h old files?
Whoops, I _hope_ you know I meant get the files up to 24h late?.
--
Please use reply-all for most replies to avoid omitting the mailing
fuzzy_4711 schrieb:
Hi list.
rsync --omit-dir-times --size-only -avzAX \
--bwlimit=$KILOBYTES_PER_SECOND --devices --specials --numeric-ids \
--delete $BACULA_BACKUP_DIR $MOUNT_DIR/$SYNC_DIR
I miss -c (or --checksum) there.
You never know whether the filesize changed, or whether the time is
Last cwrsync was 4.1.0, current is 4.2.0.
It was avail on sourceforge.
Itefix.no decided we want money for coding and support - that itself
is not wrong. Though _I_ never needed any rsync help on neither linux
and windows (including mixed) scenarios.
But they killed their sourceforge
20 matches
Mail list logo
