New answers tagged

0

for dir in $(find DIR1 -type d) ;do newdir=$(echo ${dir} | sed -e "1,1s/^DIR1/DIR3/") mkdir -p ${newdir} done This block above creates all directories in DIR1 under DIR3. If you are creating new directories under DIR1, which are not in DIR2, you should run this snippet when there are new directories under DIR1, otherwise, running this once will be ...


2

The set of options could be visualized by using printf: $ printf '<%s> ' "-e ssh -axhPv" arg2 arg3 ; echo <-e ssh -axhPv> <arg2> <arg3> If quotes are removed, this is what you get: $ printf '<%s> ' -e ssh -axhPv arg2 arg3 ; echo <-e> <ssh> <-axhPv> <arg2> <arg3> That is: ...


1

It is certainly possible to use the file list generated during a dry run as an include file. Ideally, however, the extra lines at the top and bottom of the dry-run output should be deleted. Example output: sending incremental file list [LIST OF FILES] sent 226 bytes received 34 bytes 520.00 bytes/sec total size is 648,373,274 speedup is 2,493,743.36 ...


1

When you quoted the rsync_options to the rsync command, you passed all of those options as one argument to rsync, instead of as separate options. Thus, rsync was trying to run ssh with the "-axhPv" flags. Demonstration time: function showme () { echo First: $1 echo Second: $2 echo Third: $3 } $ showme "-e ssh -axhPv" two three First: -e ssh -axhPv ...


0

I think the argument for -e needs to be in quotes itself. rsync -axhPv -e 'ssh -p 2222' user@host:/source_dir/ /dest_dir/ So you might need to do something along the lines of: rsync_options="-e 'ssh' -axhPv" You may or may not need to escape the single quotes inside the doubles.


0

Command you have used --delete-during will delete the files in receiving side /mnt/usb0/backup/partition2 However check your --exclude-from file /etc/rsync-exclude.txt has the name test.txt in it. You can also use below options, --delete-before receiver deletes before xfer, not during --delete-during receiver deletes during ...


1

It means that the receiver/destination has so far reconstructed 105.45 megabytes (or 13%) of the approx. ~811.15 megabytes (100%) of the sender's/source’s files. These files are being reconstructed at a rate of 602.83 kilobytes per second, and this data transfer operation is estimated to finish in 2 minutes and 50 seconds. Also, xfr#495 means that currently ...


0

You mentioned you see TCP RST packet whenever this fails. This sounds similar to the issue of a firewall potentially disconnecting as mentioned on the following post, which also has a work around by re-using a hanging ssh connection. rsync-connection-closing-right-around-an-hour There's also an option of --timeout=[timeout value] but I think it's not as ...


1

Do both use the same filesystem? Different filesystems may have different blocksizes so the filesize may be different.


1

Rsync "handles" it by ignoring it. Does that count? Not really... Any changes that get made after rsync copies that portion of the file are lost and not copied. This can mean that different parts of the same file contain data from different points in time. As you suspected, this can be a problem. A workaround I often use on linux (saw your tag) is to ...


1

For backups and real-time synchronization I use glusterfs. Is a very friendly and robust sync & backup package. See more about glusterfs in here.


0

So long story short, this is the best way I have found to achieve this, in case someone else is interested: find /mnt* -type d -name snapshots > dir.list; \ tar -czpf - -T dir.list | ssh user@host "openssl aes256 \ -out /mntc/backups/snapshot.tgz.enc -salt -k 'secret'"


1

man rsync: If DIR is a relative path, it is relative to the destination directory. You need: rsync -av --dry-run --itemize-changes --compare-dest="$PWD"/test test2/ result/


0

So it's a permissions problem. The FAT filesystem mounted by root cannot be accessed by normal users. It's a result of the fact that FAT doesn't include ownership information, so all files are considered owned by the user who mounted it.[1] The chown error message is because you're trying to copy files owned by you, to the FAT filesystem, using the -a ...


0

rsync -avr --delete-excluded --include=*.txt /source /* /destination May help your needs. Let me know.


4

You can use the option --inplace This option changes how rsync transfers a file when its data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is complete, rsync instead writes the updated data directly to the destination file. so ...


1

Always try to see if there's already a similar discussion before posting the question. With rsync, all exclude (or include) paths beginning with / are are anchored to the root of transfer. The root of transfer in this case is /share. Use relative path, instead of absolute path and it should work. For further reference, rsync exclude directory not working


1

Never mind: I've found the solution. An app called M3Unify is able to produce playlists and also export the music within the exported playlists. What makes this app different is that it can also rename the files it exports using tag substitution patterns, and can export the files as subfolders, with specific instructions detailing how the files are put in ...


1

When rsync believes it's accessing both source and destination on the same host it does not use its incremental transfer. Instead, it simply copies the entire file. This is the situation in your case. As a result, your second command is copying the file.so~new across your ssh fuse link to the local host, and then immediately copying it back again. Is there ...


1

You could try osync which is designed for exactly this task. I once set up a complex sequence of rsync commands to do the job, but I now use osync. https://github.com/deajan/osync It uses rsync internally, so it should be suitable for any situation where you could use rsync.


1

rsync is the wrong tool for this task, for exactly the reasons that you have encountered. Instead, consider using unison: unison A/ B/ The first time you run this it will identify files that are uniquely in A, and those that are uniquely in B. It will also flag those that are in both places and ask you to identify which is to be overwritten. The next ...


5

It doesn't delete 4.txt because you are running the rsync command with *, i.e. on the individual source files. Hence, rsync doesn't even consider 4.txt (or the containing directory). Instead, run it on the directory that contains the sources, by changing the * to . Then, rsync can look at the directory as a whole as see what is missing. rsync ...


1

I like roaima's answer, but the paths are the same in both examples, obscuring which is which. We've established that the following doesn't work: rsync -vuar host1:/host1/path host2:/host2/path But this does (I omitted the explicit bind_address of localhost from the -R option since that's the default): ssh -R 50000:host2:22 host1 'rsync -e "ssh -p ...



Top 50 recent answers are included