rsync for backups
Bart
files each time.
I've had a quick look at the rsync docs but was wondering if someone could save
me some time and post their backup script?
Thanks
Bart
Toronto
Piesse
http://www.os2site.com/sw/util/backup/dsync016z.zip
piersante
Thomas V.
I'm using DSYNC for years. It works very fine.
Ciao/2
Tom
Steven Levine
at 10:33 AM, Bart <gen-underscore-mgr@cbm-dot-on-.-ca> said:
Hi,
Sorry for the slow reply. I missed this post. It took the replies to get
my attention.
>I have a USB HD I use for sporadic backups. It's a nuisance to copy all
>the files each time.
To use rsync as a super xcopy command, use
rsync -a --xattrs source-path/ dest-path
--verbose and --dry-run are handy.
If something does not work, open a ticket at mantis.smedly.info.
FWIW, rsync is a lot faster than dsync if you have a lot of files and
data.
Regards,
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
--------------------------------------------------------------------------------------------
Joe Negron
>To use rsync as a super xcopy command, use
>
> rsync -a --xattrs source-path/ dest-path
>
>--verbose and --dry-run are handy.
I've tried:
rsync -a --xattrs D:\ K:\DriveD\
I get the error:
2009/05/15 14:09:38 [303] relative directory with drive letter not supported K:\DriveD\ util.c(1097)
and everything is copied to the current directory. Trailing backslash
or not doesn't matter. How do I get rsync to copy to a pathed
destination?
>If something does not work, open a ticket at mantis.smedly.info.
If my problem is not the result of misunderstanding, I will.
>FWIW, rsync is a lot faster than dsync if you have a lot of files and
>data.
This claim is the reason I'm trying to get rsync to work.
--
------------------------------------------------------------------------
If you've seen one redwood, you've seen them all.
--Ronald Reagan
War is good for business - invest your son.
--antiwar bumper sticker from the 1960s
------------------------------------------------------------------------
Joe Negron from Bensonhurst, Brooklyn, NY, USA
Mr. G
> On 2009-05-15, Steven Levine <ste...@earthlink.bogus.net> wrote:
> >To use rsync as a super xcopy command, use
> >
> > rsync -a --xattrs source-path/ dest-path
> >
> >--verbose and --dry-run are handy.
>
> I've tried:
>
> rsync -a --xattrs D:\ K:\DriveD\
>
> I get the error:
>
> 2009/05/15 14:09:38 [303] relative directory with drive letter not supported K:\DriveD\ util.c(1097)
>
> and everything is copied to the current directory. Trailing backslash
> or not doesn't matter. How do I get rsync to copy to a pathed
> destination?
>
> >If something does not work, open a ticket at mantis.smedly.info.
>
> If my problem is not the result of misunderstanding, I will.
>
> >FWIW, rsync is a lot faster than dsync if you have a lot of files and
> >data.
>
> This claim is the reason I'm trying to get rsync to work.
>
Try quotes around your destination path.
Steven Levine
at 06:15 PM, Joe Negron <jne...@XsonicX.net> said:
Hi,
>I've tried:
> rsync -a --xattrs D:\ K:\DriveD\
What build are you running? The failure implies it's somewhat antique.
Your command line should work with a more current build.
As you might expect the linux guys don't generally write code that
supports drive letters or backslash directory separators.
You can try
http://download.smedley.info/rsync-3.0.5-os2-20090412.zip
Paul built it with my diffs, so hopefully, it will just work. If not, log
in to
http://mantis.smedley.info/view.php?id=304
and grab the build that is attached to the ticket. This is my build.
>This claim is the reason I'm trying to get rsync to work.
It's a valid claim. Rsync is an elegant piece of work.
Steven Levine
at 10:37 PM, "Mr. G" <nos...@yahoo.com> said:
Hi,
>> rsync -a --xattrs D:\ K:\DriveD\
>Try quotes around your destination path.
FWIW, this will not help, because the arguments contain no white space.
This assume he user is running cmd.exe or 4os2. I would say something
different if the user was running a *nix shell such as bash.
Joe Negron
>In <gukbgm$emb$1...@solani.org>, on 05/15/2009
> at 06:15 PM, Joe Negron <jne...@XsonicX.net> said:
>
>Hi,
>
>>I've tried:
>
>> rsync -a --xattrs D:\ K:\DriveD\
>
>What build are you running? The failure implies it's somewhat antique.
>Your command line should work with a more current build.
"rsync version 3.0.5 protocol version 30".
>As you might expect the linux guys don't generally write code that
>supports drive letters or backslash directory separators.
Yes, one of the issues we must live with when using linux ported
software.
That's what I have.
>Paul built it with my diffs, so hopefully, it will just work. If not, log
>in to
>
>http://mantis.smedley.info/view.php?id=304
I created an account but was not sent the confirmation e-mail.
>and grab the build that is attached to the ticket. This is my build.
>
>>This claim is the reason I'm trying to get rsync to work.
>
>It's a valid claim. Rsync is an elegant piece of work.
My faith in the claim is why I'm spending time trying to get it to work.
:)
--
------------------------------------------------------------------------
Friendship is one mind in two bodies.
--Mencius
Steven Levine
at 02:00 PM, Joe Negron <jne...@XsonicX.net> said:
Hi,
>Yes, one of the issues we must live with when using linux ported
>software.
That's the problem. It appears I still have at least one place left to
map backslashes to forward slashes. I'll take care of this once I track
down the culprit.
For now, use
rsync -a --xattrs D:/ K:/DriveD
You can add --progress if you want to watch things go by.
If you add -stats, you will see results like on the second pass
Number of files: 91957
Number of files transferred: 1
Total file size: 4816370823 bytes
Total transferred file size: 3098 bytes
Literal data: 3098 bytes
Matched data: 0 bytes
File list size: 2167341
File list generation time: 0.316 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2201149
Total bytes received: 30677
sent 2201149 bytes received 30677 bytes 7234.44 bytes/sec
total size is 4816370823 speedup is 2158.04
Thanks for testing.
Bart
This causes rsync to stop completely.
rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (10411 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=
3.0.5]
This is a simple backup from my HD to a USB portable HD
I've googled it, but can not find anything definitive
I did find a solution suggested for a similar problem:
--bwlimit=8192 --timeout=600
I'm guessing USB transfer is slow and rsync thinks connection is lost
Has anyone else experienced this?
Bart
BTW I am using a command like::
rsync.exe -rv --del --ignore-errors --log-file=c:\craft-bilt.log --progress
C:/Craft-Bilt H:/
Steven Levine
at 05:36 PM, Bart <gen-underscore-mgr@cbm-dot-on-.-ca> said:
Hi Bart,
>rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe
>(32) rsync: connection unexpectedly closed (10411 bytes received so far)
>[sender] rsync error: error in rsync protocol data stream (code 12) at
>io.c(600) [sender=
>3.0.5]
This is odd. It implies that the receiving process is dieing for some
reason.
>This is a simple backup from my HD to a USB portable HD
>I've googled it, but can not find anything definitive
>I did find a solution suggested for a similar problem:
>--bwlimit=8192 --timeout=600
Unfortunately, this is unlikely to work. The code does not match the
docs. For a local copy like yours, you can not set the timeout to more
than 60 seconds and you can not turn off the timeout. I don't know if
this is by design. I will have to ask.
>I'm guessing USB transfer is slow and rsync thinks connection is lost
It would have to be extremely slow. I can't imagine rsync sending a block
so large that would take 60 seconds to write to the drive.
I think it's more likely that some sort of IO error is the source of your
problem.
>rsync.exe -rv --del --ignore-errors --log-file=c:\craft-bilt.log
>--progress C:/Craft-Bilt H:/
This looks OK, but you really want to add -t. The benefit of using -t is
that rsync by default transfers files with differing size or timestamp.
Without -t, you are going to copy a lot of files that don't need copying
and thus slow down your backups.
Also, -t should allow you workaround the io errors. Since you will only
copy changed files, it's likely that after a few restarts, you will have a
good backup.
You should not need --ignore-errors, but it should not hurt either.
Peter Brown
Is the USB drive fat32 formatted?
If "Yes" then a change of filesystem to something that works a lot
quicker may help - eg JFS or HPFS.
A simple xcopy of my boot drive, about 850Mb, to fat32 formatted uSB
drive is *lots* slower - about 25 mins in time - than using a JFS
formatted drive here.
You may also want to look into the "Common usb faq" which used to be
somewhere on ecomstation.ru but I cannot find the url for it currently
so here is the relevant bit:-
Q6: What is the speed of USB 2.0?
A6: Robert Lalla gives some info about USB 2.0 speed:
* USB 2.0 bus raw data speed is 60 MB/s (1 MB = 1,000,000 bytes)
* USB 2.0 theoretical max throughput is 53 MB/s
* USB 2.0 onboard controller from Intel can reach about 40 MB/s
* USB 2.0 onboard controller from VIA can reach about 30 MB/s
* USB 2.0 PCI addon card can reach about 20 MB/s
* USB 2.0 flash disk can reach from 1 MB/s to about 32 MB/s,
depending on hardware quality. Write speed is typically slower
or much slower than read speed.
* IBM USB stack has some bottleneck when writing to mass storage,
don't know where. So write speed might stay way below hardware
limits.
* IBM USB 2.0 driver (USBEHCD.SYS) is leaving USB host controller
in default speed, which keeps interrupt load low even on slow cpu.
So USB 2.0 host controller cannot reach its max speed.
Q7: How to improve USB 2.0 read performance:
A7: Robert Lalla offers a patch:
* Open command window and change current directory to \OS2\BOOT
* Verify that you have latest USBEHCD.SYS (v10.162, 42112 bytes)
and make backup copy of USBEHCD.SYS
* Copy 3 lines of text to a new file called USBPATCH.TXT:
FILE USBEHCD.SYS
VER 1723 FF76F2
CHA 1723 6A0190
* Run the following command:
PATCH USBPATCH.TXT /A
* Reboot
* In case system load is too much now when accessing USB device,
you can try out different speed settings by using different
USBPATCH.TXT containing "CHA 1723 6A0*90", where * is a hex
digit.
(1=fastest, 2=nearly_fastest, 4=slower, 8=default)
Regards
Pete
Bart
that topic was from June!
I somehow have managed to get a command line string that works.
This portable USB HD has 3 partitions: jfs, fat32 and ntfs
From my work PC I back up different directories to the jfs & fat32
From home I back up the kids PC to the ntfs partition
Bart
Kelbel
Hello,
I jump in this USB HD discussion (sorry). My question is: After using
USB ext. HD, the eject command shows an error msg "disk not functionning
properly" or the like. Is there a way to avoid this msg ?
I also noticed that after removal of the PRM, the LVM/QUERY shows no
longer the default size (96) of the 2nd disk, but keeps the size of the
last used external USB disk. Is there a way to clean the erroneous LVM
information ? (maybe I'm not to-date with os2lvm.dmd (bld 14.96) or
lvm.dll (8/24/05, size 144480))
Thks in advance for infos.
K.
Bart
> Hello,
> I jump in this USB HD discussion (sorry). My question is: After using
> USB ext. HD, the eject command shows an error msg "disk not functionning
> properly" or the like. Is there a way to avoid this msg ?
> I also noticed that after removal of the PRM, the LVM/QUERY shows no
> longer the default size (96) of the 2nd disk, but keeps the size of the
> last used external USB disk. Is there a way to clean the erroneous LVM
> information ? (maybe I'm not to-date with os2lvm.dmd (bld 14.96) or
> lvm.dll (8/24/05, size 144480))
> Thks in advance for infos.
>
>
> K.
Sorry K, I can't answer the question.
Maybe start a new post with an appropriate subject.
Bart
Toronto