Tag Info

New answers tagged

0

We called our hosting provider, we do some tests while server is up. But nothing. Finally, I just reboot the server and it's works now... I did not do this before because it's a production server


0

1) Check destination space. ssh login@192.168.1.4 df -h /srv/data2_http 2) try the --inplace option of rsync. It prevents using more space, but makes destination files inconsistent during transfer.


1

rsync transfers contents to a temporary file, in the target folder, first; if it succeeds it renames that temporary file to become the target file. if the transfer fails, it deletes the temporary file. a 2GB file would have filled up your target space then after rsync deletes it the space is available again. so, rsync can trick your investigation of the ...


2

Your case sounds exactly what lsyncd was made for. It watches the directory with inotify and spawns an rsync with only the changed file(s). It aggregates changes for a few seconds. So when you make 5 changes in one second it will only spawn one new sync process to the destination server(s).


3

AFAICT rsync on it's own can't do this. Switch the system to use LVM/ZFS/btrfs/something else with snapshots, mount the snapshot, and rsync that. Then remove the snapshot. For example, with LVM: # Allow 1GB of changes to occur while the rsync occurs lvcreate --snapshot my_vg/my_lv --size 1GB --name backup mount /dev/my_vg/backup /mnt/temp # ... rsync goes ...


0

If ulimit value is 0 or a little number, it should be giving that error. Try to increase ulimit value (such as 9999999999) and try again. you can write a little shell script (a.sh) and use something like this: #!/bin/sh ulimit 99999999999 rsync -avrz --perms --delete --chmod=u+rwx,g+rx,o+x /dir1/ /dir2/


0

You can supplement it by Rsync --whole-file Rsync by default on local copies will just copy the whole file, but to reduce network traffic remote syncs are diff'd which greatly increases the CPU load. rsync -av --whole-file -e ssh {source} {destination} Source


0

Seems like I found the ticket. Drop the --chmod=ugo=rwX which of course means later on when trying to access the backups one might get permission denied due to windows NTFS ACL etc but I assume if viewing it on Linux that Linux's ntfs mount tools will ignore that junk and not care. Someone please correct me if I'm wrong on that. Anyway its still a bit ...


0

Are you really bound by rdiff-backup or you are OK using plain rsync to do incremental backups? Here's a small script that keeps 4 incremental backups. You can change it easily to keep 9 or 99 incremental backups or any other number. It uses the --link-dest option from rsync, creating hard links if files are unchanged. FROM=$HOME TO=/var/backups ...


1

It works for me: $ rsync --hard-links --recursive --link-dest=/local user@host:/remote/ /local I use rsync version 3.1.0. From man: --hard-links Tells rsync to look for hard-linked files in the transfer, without this option, hard-linked files in the transfer are treated as though they were separate files. --link-dest=DIR Unchanged ...


1

The public key root login over SSH is likely your best bet. You could furthermore restrict this access to a single host: AllowUsers root@192.0.2.123 Or even use the Match directive to get a unique configuration for a given something (address, user, etc): Match Address 192.0.2.123 PasswordAuthentication no RSAAuthentication yes ...


1

Try rsync rsync -u <src> <dest> it will copy filest but if file exists it will skip files that are newer on the destination


1

I use duplicity instead of rdiff-backup but from my understanding your problem is here: My idea was to transfer data initially on physical media to remote server. After that transfer I synchronized the data by rync to make sure they are identical. Now I want to do intial rdiff-backup. Solution that works The simplest solution is to rdiff-backup to ...


0

I don't think that your problem is really related to directory timestamp. With so much data, rsync will simply need some time to discover changed files and to begin to transfer them. If the meantime it discover a directory a/m/ctime change it will replicate that change on the receiver side, but this should be almost instantaneous.


0

In the scenario you described (failed source drive), rsync will not delete anything, because: by default, rsync does not delete anything until you pass it the "--delete" option even passing it the "--delete" option, rsync will not remove a destination file if the source disk can not be accessed. From the man page: If the sending side detects any I/O ...


0

You can try using rsnapshot. This uses rsync to create a backup based on hardlinks. On the server, multiple backups can be accessed without wasted space. So when your drive A is erased, only the newest backup will have the data "erased", but the old snapshots will still hold the data. Another thing to do is using the options --backup and --backup-dir ...


0

Oh, you can set rsync up to not delete extraneous files. By default it doesn't. So if all the files are gone from drive-a, they should be fine. http://unix.stackexchange.com/questions/5451/delete-extraneous-files-from-dest-dir-via-rsync


0

when i using GlusterFs we have a bottleneck with T files with zero size, for sync between crashed brick or replica we must use --min-size=1 to not syncing empty file from crashed server


4

Your rsync have probably messed up your rights with /root/ or /root/.ssh/ folders. Your /root folder owner is not root anymore and your chmod should be 700. The following commands should fix the problem chmod 700 /root chown root:root /root chown -R root:root /root/.ssh


0

I had similar frustrations, so I ended up creating a few scripts which I'm calling snazzer. Together they offer snapshotting, pruning, measurement and transport via ssh (but as of today can send/receive to/from local filesystems as well). Measurements are just reports of sha512sum and PGP signatures of snapshot paths. It's not quite ready for release but I ...


1

sshfs won't help with this; what you need to do is add the -W option to tell rsync to just transfer whole files, without trying to figure out where the specific differences are. You might also need to remove --inplace (not sure about that). rsync is really designed for remote operations where there's an rsync instance (or daemon) on each computer, each with ...


3

Set the service to manual start. In the same script that you run to copy the files, start the service. This script can be run by the task scheduler as any user.


2

No, it will not be better with sshfs. It can't be, as with locally mounted remote file systems, the local rsync process has to read the file to see what needs to be copied. For this, the whole file has to be transported via the network.


1

Just ran into this problem. And if you want rsync to treat symlinked directories as directories, you want the K option rsync -K /files/ user@server:/files/


0

As jlehtinen says above, Active Directory Group Policy Objects (GPOs) can be used to push software out to selected AD clients. It's not massively difficult, but relies on the software install to be packaged in an MSI format. This isn't normally an issue. However, the post-install configuration also needs to be carried out. There are two options here - ...


1

No, rsync does not check the access time (atime) of a file. Instead, it use the modified and changed times (ctime/mtime) to check if a file changed. What you should pay attention, however, is that rsync is preserving mtime (-t option) in the fist place. If not, any further attempt will re-sync the same files. rsync -a includes '-rlptgoD' options, so if you ...


1

The data.mdb file is actually a thin provisioned 86GB (by default) file. Rsync and sometimes cp commands will 'explode' the file to it's full size when copying to a backup directory. This obviously doesn't help if you want to create an offsite backup or if you are limited in resources. This behavior seems new in 8.0.1 The proper way to prevent this is to ...



Top 50 recent answers are included