New answers tagged

0

Solution: a few popt library file was overwritten by someone on the TARGET side. re-installed popt on target side.


0

I had the same trouble, you have to do: rsync -avh --dry-run --compare-dest=/run/media/user/centos6/updates/x86_64/ /home/REPOS/6/updates/x86_64/Packages /path/to/updates Note --compare-dest is the parent of Packages and do not put "/" at the end of source folder!


1

This problem is best solved at the rotation stage, not at the copy-and-archive stage. If you change the log rotation to date the files rather than give them sequential numbers, then the rsync archival doesn't need any logic to do the Right Thing™. Assuming you are already using logrotate for rotation, then this can be done with the dateext option. But if ...


0

At the end of a transfer, rsync checks that the file it has transferred matches the one is started transferring. If the files mismatch it warns you and moves on to the next one. If you have --remove-source-files it will not remove a file that it believes has been incorrectly or incompletely transferred. Provided that there is a window of opportunity during ...


0

I personally use this simple one: ls -1 | parallel rsync -a {} /destination/directory/ Which only is usefull when you have more than a few non-near-empty directories, else you'll end up having almost every rsync terminating and the last one doing all the job alone.


1

ext4 uses POSIX ACLs (when they are explicitly enabled via the acl mount option). ZFS uses NFSv4 ACLs (at least on FreeBSD). As the rsync man page states: -A, --acls The source and destination systems must have compatible ACL entries for this option to work properly. Without the -A option, the transfer works without any problems.


2

You can do this with find and touch. cd destination find -depth -exec touch -r /path/to/source/{} {} \; The -depth option arranges for directories' times to be set after their contents have been set. This assumes that your find interpolates {} when it's a substring of an argument. If it doesn't, invoke a shell: find -depth -exec sh -c 'for x; do touch -r ...


3

This worked well for me: rsync -vrt --size-only /src /dest The --size-only command compares files only based on size, which was largely unchanged for me. The -t copies over the timestamps.


2

There might be a limit on 32 bit versions of these applications, especially older versions not compiled with "large file support". Those problems were not a result of packets being dropped, but on writing (and/or reading) the files at the appropriate size. Back in 1995 there were similar problems with tar under Irix not support files > 2Gb. So make sure you ...


-1

Check also if rsyncd.conf has proper rights set: chmod 640 /etc/rsyncd.cond


0

Although you are not using -a nor -g the second rsync -i is wanting to update the group owner of the file. Try adding as 2nd arg: --no-g.


0

Though this is an old one I would like put David's response into an "lsyncd" context. A sample configuration could look like this (tested and confirmed on one of my systems): sync { default.rsyncssh, source = "/tmp", host = "gw2", targetdir = "/tmp", delete = false, rsync = { _extra = { "--files-from=/etc/lsyncd/files.list" } } } With ...


1

What you are doing there is at least 'complicated'. As far is i understood, you connect to one server, and tell it to sync to another server. For ease of use, you may specify port and user to use in the local ssh configuration for a particular host. for instance, if you add the following lines to the file ~/.ssh/config (/home/username2/.ssh/config) on the ...


2

SSHFS is convenient, but it doesn't mesh well with rsync or more generally with synchronization tools. The biggest problem is that SSHFS largely kills rsync's performance optimizations. In particular, for medium to large files, when rsync sees that a file has been modified, it calculates checksums on parts of the file on each side in order to transfer only ...


2

To answer your main question: yes there are differences. With sshfs there is an existing connection to allow access to remote files over a secure channel and with rsync over ssh, that secure channel is set up to talk to a remote rsync instance. To answer your secondary question: The rsync over ssh will be faster for most, if not all instances, because the ...


1

In --dry-run mode, rsync determines which files need to be transferred but doesn't actually transfer their data - 'cuz there's no use to do that, naturally. This implies it doesn't perform delta matching - because it's a part of data transfer logic. The reason for the numbers reflecting that is... well... that the code shows actual statistics, not some ...


0

Your source is probably not ZFS? Otherwise zfs send|zfs receive would be recommended. You can tell rsync to perform inplace transfers, from man rsync: --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 ...


1

I think I can improve on the answer given by EightBitTony. ssh -t user@target 'sudo cat /source/file' > output && chmod +x output When more than one file is involved, I find pax much easier to use than rsync, not matter how often rsync is "simplified" for me. ssh -t user@target 'cd /src && pax -w ./' | pax -r HTH.


1

I've seen this when 64bit libraries are installed on 32bit kernels and vice versa.


0

ssh -t user@target machine sudo cp /source/file /target/file The -t creates a pseudo-tty, so that sudo can ask for a password. The ssh command takes an optional command (sudo cp .... in this case) which it executes on the target machine and then disconnects. You will get prompted for the sudo password (i.e. user@target's password). You can then run the ...


0

Your comment with output from itemize-changes shows the only relevant flag set is T. From the man page: A t means the modification time is different and is being updated to the sender’s value (requires --times). An alternate value of T means that the modification time will be set to the transfer time, which happens ...


0

You can have a look at these link Unison & rdiff-backup


3

If you use an absolute path in a filter (include/exclude), it's interpreted starting from the root of the synchronization. You aren't excluding a directory in the source, or a excluding a directory in the destination, you're excluding a directory in the tree to synchronize. Thus: rsync -av --delete --progress --exclude "/folder4/mytestfolder1" /source/ ...


0

Do you really need to use NTFS compression? Maybe will be better to compress with .tar.tgz using --rsyncable option. It will only send the differences of .tar.gz and will save network bandwidth. If you really need more compress level, you can use gzip -9. And if you really need save more space, you can use rdiff-backupt to save only the differences (you ...


1

When a filesystem provides compression it is usually intended to be transparent, so that there should be no difference between the original file and a compressed version, apart from some meta-data such as the actual number of physical blocks used. This would seem to be the case with Linux NTFS-3g. By default rsync only compares timestamps and sizes of files ...


2

According to the man page on rsync: "...Blank lines in FILE and lines starting with ’;’ or ’#’ are ignored..." I just ran a quick test and indeed # and ; lines are ignored.


0

Two suggested answers are specific to Linux. Here's a suggestion, sticking to POSIX: #!/bin/sh find "$@" -type f |\ xargs du -s |\ awk 'BEGIN {total = 0;} { total += $1; } END { print total; }' Alternatively, you could attempt to work around spaces in pathnames (still POSIX): #!/bin/sh find "$@" -type f -exec du -s {} + |\ awk 'BEGIN {total = 0;} { ...


1

If you have GNU find, you can make it print the file sizes. find /source ! -type d -printf '%P %s\n' Sort the output to get deterministic output. If the filenames contain newlines, it's possible to get the same sorted output for different arrangements, but that's not going to happen unless deliberately engineered. comm -3 <(find /source ! -type d ...


3

Simply feed it a list of everything you DO want counted using --files0-from find -type f -print0 | du --files0-from=-


-1

I believe what you are looking for is --max-depth. So for example. If you wanted to calculate the disk usage of a directory without all of its subdirectories this is how it would be done. du [directory name] --max-depth=1 If you wanted to find the size of its subdirectories too just increase the depth. I found a link that gives a lot of information on ...


1

Generic FUSE options 1) I noticed allow_other wasn't set on the ntfs-3g filesystem mount. The default for FUSE is not to allow access by other users. mhddfs is a FUSE filesystem and so is ntfs-3g (but see next section). 2) When you use allow_other, you also want to consider permissions checking. The default for FUSE is not to check permissions. So just ...


0

The rsync way given by Thane with Yamaneko additions work great but leave empty directories. For me the final solution was in two steps, first call rsync with full path, then a find command to remove all empty directories: rsync -rvcm --compare-dest=/tmp/org/ /tmp/new/ /tmp/difference/ find /tmp/difference/ -d -type d -empty -exec rmdir {} \; -print ...


2

You can usefully add the -i option to rsync to make it show you why it wants to copy the file again. For example, you might see .f...po.... somefilename which means the remote file has different permissions and owner. One solution is to use --size-only to only compare the sizes of files, but obviously this might cause some changed files not to be sent. ...


2

What I have done a couple of times when I wanted to move huge files and not have my rsync-based backup-script re-copy it, is to make a hardlink in the new location, run the backup-script (the -H option to rsync is the important one here) and then remove the old location. It sounds like you have done the rename/move, then I see two options: Perform the ...



Top 50 recent answers are included