Re: --link-dest. Time to 'building file list' incrementing

Don't know how I missed this when I was trying to figure out the cheapest solution. I don't need the complexity but it seems to be worth investigating. ThanksOn 8 Jan 2019 16:15, Andrew McGlashan via rsync wrote: > > On 8/1/19 8:56 pm, John Simpson via rsync wrote: > > Any ideas anyone? > > How

Re: --link-dest. Time to 'building file list' incrementing

On 8/1/19 8:56 pm, John Simpson via rsync wrote: > Any ideas anyone? How about using snapshots and doing the rsync off those? https://www.thewindowsclub.com/vss-volume-shadow-copy-service https://blogs.technet.microsoft.com/josebda/2007/10/10/the-basics-of-the-volume-shadow-copy-service-vss/

Re: --link-dest. Time to 'building file list' incrementing

Thanks. I'll give this a go and report back. On 8 Jan 2019 10:03, Ben RUBSON wrote:Hi,As you are on Cygwin, you should consider the notexec & noacl mount options :https://cygwin.com/cygwin-ug-net/using.html#mount-tableThey impact stat() performance.BenOn 8 Jan 2019, at 10:56, John Simpson via rsyn

Re: --link-dest. Time to 'building file list' incrementing

Hi, As you are on Cygwin, you should consider the notexec & noacl mount options : https://cygwin.com/cygwin-ug-net/using.html#mount-table They impact stat() performance. Ben > On 8 Jan 2019, at 10:56, John Simpson via rsync wrote: > >

Re: --link-dest. Time to 'building file list' incrementing

Any ideas anyone? I still need at least a weekly backup of all data. The current workaround is just for the most active directories. Are there any diagnostics I can do which might shed some light on this? Thanks JohnOn 4 Jan 2019 09:53, John Simpson via rsync wrote: > > Kevin > > The link-des

Re: --link-dest. Time to 'building file list' incrementing

Kevin The link-dest parameter is a single directory (the previous day's directory), the destination is today's directory. I haven't tried deleting a backup, there's no particular need in space terms, at the current rate there's enough space for several years of daily backups. I've reverted t

Re: --link-dest. Time to 'building file list' incrementing

It does normally take some time to analyze large trees of files. It has to call stat() on each file to get the size and timestamp. However, 15 hours seems a bit excessive even though I have never tried to do this on Windows or a NAS system. Just to be clear, is your --link-dest parameter a singl

Re: Aw: Re: link-dest and batch-file

Von: "Kevin Korb via rsync" >> An: rsync@lists.samba.org >> Betreff: Re: link-dest and batch-file >> >> If you are using ZFS then forget --link-dest. Just rsync to the same >> zfs mount every time and do a zfs snapshot after the rsync finishes. >> Then de

Aw: Re: link-dest and batch-file

But don‘t forget —inplace, otherwise snapshots would not be efficient > Gesendet: Mittwoch, 18. Juli 2018 um 21:53 Uhr > Von: "Kevin Korb via rsync" > An: rsync@lists.samba.org > Betreff: Re: link-dest and batch-file > > If you are using ZFS then forget --link-d

Re: link-dest and batch-file

If you are using ZFS then forget --link-dest. Just rsync to the same zfs mount every time and do a zfs snapshot after the rsync finishes. Then delete old backups with a zfs destroy. On 07/18/2018 03:42 PM, Дугин Сергей via rsync wrote: > Hello. > > I need that during today's backup, the meta

Re: link-dest and batch-file

Hello. I need that during today's backup, the metadata about the files is saved in a file, so that tomorrow when creating a backup with the option "link-dest" instead of this option I would specify a file with metadata, then rsync will not scan the folder specified in "link-d

Re: link-dest and batch-file

You have to have a script that places a "successful" file in the root of the completed rsync... And use that to figure out what to do for link-dest at the top of the script... I use something more like daily.0-daily.7 and monthly.0-monthly.3 for the folders and rotate them daily -if- the "succes

Re: link-dest and batch-file

I don't know how the OP manages their backups. I write out a backupname.current symlink pointing to the new backup once it is completed. That is what I use as the --link-dest parameter and what I would restore from. If a backup is aborted in the middle, doesn't happen at all, or fails the symlin

Re: link-dest and batch-file

On Tue, Jun 26, 2018 at 12:02 PM, Дугин Сергей via rsync < rsync@lists.samba.org> wrote: > I am launching a cron bash script that does the following: > > Day 1 > /usr/bin/rsync -aH --link-dest /home/backuper/.BACKUP/009/2018-06-25 > root@192.168.1.103:/home/ /home/backuper/.BACKUP/009/2018

Re: link-dest and batch-file

I don't believe there is anything you can do with the batch options for this. If you added a --write-batch to each of those you would get 3 batch files that wouldn't be read without a --read-batch. If you also did a --read-batch that would contain differences between a backup and the backup befor

Re: link-dest + fuzzy twice = vanished

I just submitted a bug report : https://bugzilla.samba.org/show_bug.cgi?id=12489 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-

Re: --link-dest not working on remote server (running daemon)

If you specify your target as offsite/backup I think you should specify your link-dest as --link-dest=offsite/backup/backup-2016-02-01-0100 ...perhaps... On 02/08/2016 11:10 PM, Sam Holton wrote: > With the following server config: > > log file = /var/log/rsyncd.log > pid > file = /var/run/rsyn

Re: --link-dest not working on remote server (running daemon)

With the following server config: log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock [offsite] path = /media/external/ comment = Offsite backup read only = no hosts allow = 192.168.2.0/24 auth users = backup secrets file = /etc/rsyncd.s

Re: --link-dest not working on remote server (running daemon)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 try: --link-dest=../backup-2016-02-01-0100 On 02/08/2016 04:51 PM, Sam Holton wrote: > Thanks for the reply. The link-dest is different. It is Feb 1 while > the source is Feb 2. > > I tried setting path = /media/external/ for the daemon and using >

Re: --link-dest not working on remote server (running daemon)

Thanks for the reply. The link-dest is different. It is Feb 1 while the source is Feb 2. I tried setting path = /media/external/ for the daemon and using rsync -a -v -i --delete --link-dest=backup-2016-02-01-0100 --password-file=/media/external/scripts/offsite_rsync.pass /media/external/backup/ba

Re: --link-dest not working on remote server (running daemon)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 by misaligned I meant that your source is a directory, your link-dest is a directory (with the same name even), and your target is the root of the share. All 3 params should be directories and the link-dest param should be a different date than the ot

Re: --link-dest not working on remote server (running daemon)

According to this thread it at least used to work https://lists.samba.org/archive/rsync/2006-April/015328.html I don't want to use SSH because I'm running this on low power ARM boards which are already connected over VPN so no need for a second layer of transport encryption. I'm not sure what you

Re: --link-dest not working on remote server (running daemon)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/08/2016 03:33 PM, Sam Holton wrote: > Hello, > > I have read through the list of previous issues regarding this > issue but haven't been able to resolve mine. I apologize in advance > for the long text and am probably doing some simple typo. I h

Re: Link-dest thinks file is newly created, but it isn't

I suspect that I've found the problem. It appears that the permissions for these directories have been turned off at some point for these directories. This might be causing the problem with --link-dest. When it tried to stat the file on the backup it couldn't and therefore did not exist. Although,

Re: Link-dest thinks file is newly created, but it isn't

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If it seeing the files as new then I agree that stat won't help. It might have explained some other itemize output. Since it is seeing the files as new then they must not be where it is looking. Meaning that your link-dest parameter must not be appr

Re: Link-dest thinks file is newly created, but it isn't

On Sat Jan 10 2015 at 5:21:33 AM Kevin Korb wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > What does --itemize-changes say about that file? Try using the stat > command on the various copies of it to see what is different about them. > In my original message, I stated I used --ite

Re: Link-dest thinks file is newly created, but it isn't

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What does --itemize-changes say about that file? Try using the stat command on the various copies of it to see what is different about them. On 01/09/2015 09:42 PM, Clint Olsen wrote: > Hi: > > I've been using rsync for a couple years now. Unfortuna

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/26/2014 09:56 PM, Askar Safin wrote: >> I mean instead of having --link-dest=previous_backup and the >> target being empty (or starting that way in your case) you cp -al >> the prevous_backup to the new "incomplete" one. Now you have a >> tree f

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I mean instead of having --link-dest=previous_backup and the target being empty (or starting that way in your case) you cp -al the prevous_backup to the new "incomplete" one. Now you have a tree full of all hard links. Now you can rsync to the target

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I was just making sure that you understood that. BTW, if you want it to always have that behavior (it can save a lot of backup space) you can use the old cp -al method instead of --link-dest so that the target dir starts out completely populated.

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am talking about metadata. Permissions, ownerships, etc. If a link exists in the target and needs a metadata change then rsync will do a chmod, chown, whatever which updates all the instances of the file. If there hadn't already been a link there r

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Then you still have the problem of already created links being updated. On 12/26/2014 08:20 PM, Askar Safin wrote: > I don't specify --partial-dir. As you can see from the script, > rsync at first copies to "in-progress", and then renames this to > (f

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Are you specifying --partial-dir? Seems like that would be needed or else you will end up would end up with an incomplete copy in the previous target? On 12/26/2014 06:50 PM, Askar Safin wrote: > Ok, thanks. I removed --inplace and --append-verify an

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, but there are issues to keep in mind... Normally --link-dest is used to keep previous copies (to make a backup system) and the target directory is always empty. In this mode - --inplace and --append-verify would be irrelevant since rsync will al

Re: --link-dest --inplace updates files without unlinking. What to do?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --inplace and --append-verify are essentially irrelevant when - --link-dest is in play. With --link-dest in play the target system must write an entirely new file even for a change in permissions or timestamps so any potential benefit by these optio

Re: Link-dest breaks on uid/gid mismatches

On 11/06/12 21:24, Kevin Korb wrote: You might want to look into --fake-super. It can store metadata things (like ownership) in the file attributes instead of setting them on the file. Thank you for the suggestion. Again, that seems to be a work-around (albeit possibly a better one)? Chris -

Re: Link-dest breaks on uid/gid mismatches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You might want to look into --fake-super. It can store metadata things (like ownership) in the file attributes instead of setting them on the file. On 06/11/12 15:25, Chris Davies wrote: > I want to use rsync to backup a couple of Windows systems to

Re: --link-dest isn't linking

On Mon 23 Apr 2012, dar...@chaosreigns.com wrote: > On 04/23, Paul Slootman wrote: > > On Sun 22 Apr 2012, dar...@chaosreigns.com wrote: > > > > > rsync -Ha --link-dest=/media/4tb/bak/panic-2012-01-01 > > > /media/2tb/bak/panic-2012-02-01 /media/4tb/bak/ > > > > > > root@dancer:/media/4tb/bak# l

Re: --link-dest isn't linking

On 04/23, Paul Slootman wrote: > On Sun 22 Apr 2012, dar...@chaosreigns.com wrote: > > > rsync -Ha --link-dest=/media/4tb/bak/panic-2012-01-01 > > /media/2tb/bak/panic-2012-02-01 /media/4tb/bak/ > > > > root@dancer:/media/4tb/bak# ls -l panic*/home/darxus/_latest.jpg > > -rw--- 15 darxus

Re: --link-dest isn't linking

On Sun 22 Apr 2012, dar...@chaosreigns.com wrote: > rsync -Ha --link-dest=/media/4tb/bak/panic-2012-01-01 > /media/2tb/bak/panic-2012-02-01 /media/4tb/bak/ > > root@dancer:/media/4tb/bak# ls -l panic*/home/darxus/_latest.jpg > -rw--- 15 darxus darxus 100772 1999-09-14 21:19 > panic-2011

RE: --link-dest isn't linking

darxus wrote: > rsync -Ha --link-dest=/media/4tb/bak/panic-2012-01-01 > /media/2tb/bak/panic-2012-02-01 /media/4tb/bak/ > > root@dancer:/media/4tb/bak# ls -l panic*/home/darxus/_latest.jpg > -rw--- 15 darxus darxus 100772 1999-09-14 21:19 > panic-2011-12-20/home/darxus/_latest.jpg >

Re: --link-dest isn't linking

On 23.04.2012 06:42, Henri Shustak wrote: > >> rsync -Ha --link-dest=/media/4tb/bak/panic-2012-01-01 >> /media/2tb/bak/panic-2012-02-01 /media/4tb/bak/ > > It seems that you may be attempting to hard-link between two file systems. > One is mounted as "/media/4tb" the other is mounted as "media/

Re: --link-dest isn't linking

> rsync -Ha --link-dest=/media/4tb/bak/panic-2012-01-01 > /media/2tb/bak/panic-2012-02-01 /media/4tb/bak/ It seems that you may be attempting to hard-link between two file systems. One is mounted as "/media/4tb" the other is mounted as "media/2tb". My understanding is that it is not normally

Re: --link-dest doesn't work if target file exists (but needs updating)

> On 12-01-20 06:01 PM, Kevin Korb wrote: >> Someone has requested it: >> https://bugzilla.samba.org/show_bug.cgi?id=7870 > > I'm not really sure that is the same bug. Maybe it is. Not convinced > though. I guess I can file my own bug and ask 7870's OP to see if it's > the same issue. > >> Bu

Re: --link-dest doesn't work if target file exists (but needs updating)

On 12-01-20 06:01 PM, Kevin Korb wrote: > Someone has requested it: > https://bugzilla.samba.org/show_bug.cgi?id=7870 I'm not really sure that is the same bug. Maybe it is. Not convinced though. I guess I can file my own bug and ask 7870's OP to see if it's the same issue. > But is seems like

Re: --link-dest doesn't work if target file exists (but needs updating)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Someone has requested it: https://bugzilla.samba.org/show_bug.cgi?id=7870 But is seems like an rm -rf and a cp -al would do the same thing. On 01/20/12 17:56, Brian J. Murrell wrote: > On 12-01-20 05:42 PM, Kevin Korb wrote: >> Am I understanding ri

Re: --link-dest doesn't work if target file exists (but needs updating)

On 12-01-20 05:42 PM, Kevin Korb wrote: > Am I understanding right that your source and your link-dest are > actually the same path? Yes they are! > If so what are you trying to do that wouldn't > be accomplished with a simple 'cp -l'? Not all of the files in source and dest are supposed to be t

Re: --link-dest doesn't work if target file exists (but needs updating)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am I understanding right that your source and your link-dest are actually the same path? If so what are you trying to do that wouldn't be accomplished with a simple 'cp -l'? Also, when using --link-dest the target is treated differently. Normally the

Re: link-dest question revisted

On Thu 01 Jul 2010, d...@safeport.com wrote: > In checking inodes I can find many files that did not change on the > server. E.g.: > > artemis:/mnt# diff 201003/newharbor/home/allvid/allvid.tgz > 201007/newharbor/home/home/allvid/allvid.tgz > artemis:/mnt# ls -il 201003/newharbor/home/allvid/all

Re: link-dest question

On Tue, 5 Jan 2010, Wayne Davison wrote: On Mon, Jan 4, 2010 at 12:33 PM, wrote:  rsync -vaxH --numeric-ids --delete --exclude=/home/apache/logs \   --link-dest=/mnt/200912/newharbor/home -e ssh newharbor.safeport.com:/home \   201001/newharbor/home/ Is that newharbor/home/

Re: link-dest question

On Mon, Jan 4, 2010 at 12:33 PM, wrote: > rsync -vaxH --numeric-ids --delete --exclude=/home/apache/logs \ > --link-dest=/mnt/200912/newharbor/home -e ssh newharbor.safeport.com:/home > \ > 201001/newharbor/home/ > Is that newharbor/home/home dir really desired? Without a trailing slash on

Re: link-dest question

On Mon 04 Jan 2010, d...@safeport.com wrote: > > The command works but copies all files, i.e. no hard links created. > > rsync -vaxH --numeric-ids --delete --exclude=/home/apache/logs \ >--link-dest=/mnt/200912/newharbor/home -e ssh newharbor.safeport.com:/home > \ >201001/newharbor/ho

Re: --link-dest not working?

On Mon, Dec 7, 2009 at 7:27 PM, Matt McCutchen wrote: > On Mon, 2009-12-07 at 19:21 -0800, Parke Bostrom wrote: >> Why is rsync with --link-dest not working as I expect it to in the >> following example? > >> rsync -a --link-dest=a a/ b/ > > >From the man page: > > --link-dest=DIR > [...] If DIR i

Re: --link-dest not working?

On Mon, 2009-12-07 at 19:21 -0800, Parke Bostrom wrote: > Why is rsync with --link-dest not working as I expect it to in the > following example? > rsync -a --link-dest=a a/ b/ >From the man page: --link-dest=DIR [...] If DIR is a relative path, it is relative to the destination directory. So y

Re: --link-dest=server::location/folder

On Fri, 2009-02-13 at 04:24 -0700, lewis butler wrote: > Hate to bug you again, but I went ahead and installed 3.0.5 and looked > at --help and didn't see anything about incremental recursion. Incremental recursion is not mentioned in the --help output, but there's some information about it in t

Re: --link-dest=server::location/folder

On 11-Feb-2009, at 14:44, Matt McCutchen wrote: On Wed, 2009-02-11 at 14:12 -0700, lewis butler wrote: rsync -aCHh --stats --link-dest=akane::backup/ranma.daily.1 / myserver::akane/ranma.daily.0 rsync -aCHh --stats --link-dest=../ranma.daily.1 \ / myserver::akane/ranma.daily.0 rsyn

Re: --link-dest=server::location/folder

On Wed, 2009-02-11 at 14:12 -0700, lewis butler wrote: > I'm wondering if I can use link-dest to compare rsync to a remote > directory. > > rsync -aCHh --stats --link-dest=akane::backup/ranma.daily.1 / > myserver::akane/ranma.daily.0 > > Something like that? Is it going to work like it does

Re: --link-dest, update permissions w/o creating a new file

On Sun, 2008-11-23 at 12:04 -0500, Matthew Monaco wrote: > I like the behavior of first doing: > cp -al /backup/old /backup/new > rsync /source /backup/new > > This way permissions will be updates throughout all snapshots (I really > don't want multiple copies of my entire music collection if I de

Re: --link-dest but only if rsync detects differences

> > But with link-dest you are not creating a new backup; you are only creating > new LINKS to the same backup. > > If the new backup has no changes from the last backup, it takes up no > space, so why does it matter? You simply expire your old backup off > automatically with a rotate script. > >

Re: --link-dest but only if rsync detects differences

On 13-Nov-2008, at 14:17, Daniel Jarboe wrote: I'm currently using rsync and --link-dest to give me something like a poor-man's incremental snapshot to disk. But I really only want to generate a new backup if rsync detects differences, otherwise I don't need a new backup. But with link-d

Re: --link-dest but only if rsync detects differences

> > > I don't believe there is any better way than the two you have suggested: > run and delete if there were no changes, or check first with -n. Note > that with the first approach, you don't need a separate diff command; > you can just use -i and check whether the itemize output is nonempty. > >

Re: --link-dest but only if rsync detects differences

On Thu, 2008-11-13 at 16:17 -0500, Daniel Jarboe wrote: > I'm currently using rsync and --link-dest to give me something like a > poor-man's incremental snapshot to disk. But I really only want to > generate a new backup if rsync detects differences, otherwise I don't > need a new backup. > > Cur

Re: --link-dest but only if rsync detects differences

Maybee somone has a better approach than the "--dry-run " option? -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: link-dest to remote server doesn't work in Linux client

On Fri, 2008-10-17 at 10:02 +0800, Zhiming Zhou wrote: > Thanks very much, I noticed that the owner user and group of my "test" > files in local are changed, so rsync thought files are different from > remote rsync server, and the "--link-dest" option does works in Linux > now after run "chown". >

Re: link-dest to remote server doesn't work in Linux client

Matt: Thanks very much, I noticed that the owner user and group of my "test" files in local are changed, so rsync thought files are different from remote rsync server, and the "--link-dest" option does works in Linux now after run "chown". So, is there some option in rsyncd.conf or in rsync comma

Re: link-dest to remote server doesn't work in Linux client

On Thu, 2008-10-16 at 18:24 +0800, Zhiming Zhou wrote: > Then in cygwin, I use "--link-dest" option to do a incremental backup: > > rsync -a --force --link-dest=../old/ 192.168.0.10::ttt/new/ > > > * "new" directory contains updated files, and unchanged files are hard > linked to "old" directory

Re: --link-dest behavior

On Sat, 2008-10-04 at 18:41 -0400, Matthew Monaco wrote: > > Note (if you haven't already) that you can do the "cp" in the > > --rsync-path rather than in a separate ssh session. > > Thanks for the tip, Matt, but this does not appear to be working for me. > > I've tried rsyncing to various places

Re: --link-dest behavior

In the event that --link-dest=DIR is the option taking on the new behavior (and thus is affected by --delete), I think that the lines given by --itemize-changes should not indicate the creation of "old" directories. (or there should be yet another option to suppress these.) In the meantime - is t

Re: --link-dest behavior

On Sat, 2008-10-04 at 17:26 -0400, Matthew Monaco wrote: > In the event that --link-dest=DIR is the option taking on the new > behavior (and thus is affected by --delete), I think that the lines > given by --itemize-changes should not indicate the creation of "old" > directories. I agree. > In th

Re: --link-dest behavior

On Fri, 2008-10-03 at 01:14 -0400, Matthew Monaco wrote: > I've been thinking about the current behavior of the --link-dest=DIR > option. In the absence of --delete, ALL members of DIR should be linked > to the destination (aside from those that are changed). If not, there > should at least be a

Re: link-dest storage saving on backup server not on usb hard drive

Matt, You hit it dead on. Thanks so much. This was making me crazy. Bye, Frank Matt McCutchen-7 wrote: > > On Wed, 2008-06-25 at 12:50 -0700, fglos wrote: >> I have setup rsync to backup another linux computer with the link-dest >> option >> and realized storage savings. 1st backup is 31gb,

Re: link-dest storage saving on backup server not on usb hard drive

On Wed, 2008-06-25 at 12:50 -0700, fglos wrote: > I have setup rsync to backup another linux computer with the link-dest option > and realized storage savings. 1st backup is 31gb, daily backups only take > approx 4gb. But when I rsync with link-dest to usb external drive all > backups take up 31gb

Re: link-dest storage saving on backup server not on usb hard drive

Hi, On 26/06/2008, fglos <[EMAIL PROTECTED]> wrote: > > I have setup rsync to backup another linux computer with the link-dest option > and realized storage savings. 1st backup is 31gb, daily backups only take > approx 4gb. But when I rsync with link-dest to usb external drive all > backups t

Re: --link-dest vs. special files and owner/group changes

On Thu, 24 Jan 2008 00:44:34 -0500, Matt McCutchen <[EMAIL PROTECTED]> wrote: > On Sun, 2008-01-20 at 17:03 +0100, "Jürgen Fluk" wrote: > > rsync 2.6.9 --link-dest does > > > > - not hardlink special files (symlink, device nodes) > > This doesn't take much space, but it clutters the logfiles > >

Re: --link-dest vs. special files and owner/group changes

On Sun, 2008-01-20 at 17:03 +0100, "Jürgen Fluk" wrote: > rsync 2.6.9 --link-dest does > > - not hardlink special files (symlink, device nodes) > This doesn't take much space, but it clutters the logfiles > > - change owner/groupship on the hardlink > So if I use a hard-linked-tree-per-day, i

Re: --link-dest

Matt McCutchen wrote: > The man page description of --link-dest states that rsync interprets the > path relative to the destination directory, so you need to pass > --link-dest=../b.1 . That did the trick, thanks! smime.p7s Description: S/MIME Cryptographic Signature -- To unsubscribe or chang

Re: --link-dest

On Fri, 2007-12-14 at 17:50 -0800, Alan Batie wrote: > The first step is > to be able to verify that --link-dest works on it, but I can't even get > it to work in an known-good environment --- no matter how I specify the > args to it, it's copying the file rather than linking > [151] $ rsync -

Re: --link-dest on a local filesystem

On Thu, Mar 08, 2007 at 08:56:54PM +0200, Jaco Kroon wrote: > For some strange reason, whenever I recreate the source file, even > though it's identical to the old source file --link-dest simply does not > create the link. The file isn't identical enough to hard-link unless every preserved detail

Re: --link-dest copying modified files

On Tue, 23 Jan 2007 07:39:31 -0800, Wayne Davison <[EMAIL PROTECTED]> wrote: > You're better off maintaining a symlink named "current" that points to > the most recent directory. Either that, or rename the dirs after the > transfer. Hm, that does not work as our backup software has to pick up th

Re: --link-dest copying modified files

On Tue, Jan 23, 2007 at 01:41:55PM +, [EMAIL PROTECTED] wrote: > This works except when an existing file has been modified and is now > "new" (and not the n'th hardlink) in the image. This file is copied to > the "current" directory. A hardlink pointing to the file in lastimg is > not created.

Re: --link-dest

Please consider copying the rsync list so that other people can help you and so that your messages will be available to users who have similar questions in the future. On 1/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: rsnapshot seems to work pretty well for some things. I have a question.

Re: --link-dest

On 1/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: So would you suggest each day doing this: K=`readlink newest` BK=backup.`date +"%y%m%d"` rsync -a --delete --link-dest=$K/ source/ $BK/ rm newest ln -s $BK newest But the first time I would do, just BK=ba

Re: --link-dest

On 1/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: cp -r source dest That command doesn't copy modification times, so files in dest get newer modification times than files in src, so rsync is right to not make hard links. Try "cp -a source dest" instead. Matt -- To unsubscribe or cha

Re: --link-dest

I hope this is responding to the several people who responded. Thanks for responding. You all had the same question, whether all the characteristics of the files are the same. To know for sure I have to wait till I get back to work tomorrow, Basically I did cp -r source dest this was to make an ex

Re: --link-dest

On Tue, Jan 02, 2007 at 09:17:30PM +, [EMAIL PROTECTED] wrote: > rsync -a --delete --link-dest=/home/chamberl/oldbk/ /home/chamberl/source/ > /home/chamberl/backup/ > > I make sure that /home/chamberl/source has some files exactly the same as in > /home/chamberl/oldbk/ > but evertything get

Re: --link-dest

On 1/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: rsync -a --delete --link-dest=/home/chamberl/oldbk/ /home/chamberl/source/ /home/chamberl/backup/ I make sure that /home/chamberl/source has some files exactly the same as in /home/chamberl/oldbk/ but evertything gets copiued, and no

Re: --link-dest and file/dir transfer to remote rsync daemon

On Thu, Apr 27, 2006 at 09:48:17AM -0700, Wayne Davison wrote: > rsync can get overzealous in its sanitizing of the options and > eliminate the ../ from your --link-dest option. The attached patch fixed the overzealous sanitizing of the various --*-dest options by factoring in the depth of the des

Re: --link-dest and file/dir transfer to remote rsync daemon

Wayne, On Thu, Apr 27, 2006 at 09:48:17AM -0700, Wayne Davison wrote: > I'd suggest using "/yesterday" instead, > since that will anchor at the root... Thanks a lot! Your suggestion solved my problem. I was confused about what the root of the backup directories `yesterday' and `today' really is.

Re: --link-dest and file/dir transfer to remote rsync daemon

On Wed, Apr 26, 2006 at 03:22:49PM +0200, Alexander Grahn wrote: > rsync --port=54321 -a -v --link-dest=../yesterday mydir alpha::backup/today If you don't have "use chroot = yes" in your daemon config, rsync can get overzealous in its sanitizing of the options and eliminate the ../ from your --

Re: link-dest or cp -al?

On Sat, Apr 08, 2006 at 11:36:21PM -0500, Max Kipness wrote: > cp -al /backup/Current /backup/$yesterday_date > rsync /source/ /Current/ [...] With that combination of commands, the rsync command can affect the permissions on files in the backup directory (or directories) when it adjusts the permi

Re: --link-dest / --hard-links problem

I'm now using rsync-HEAD-20050424-0034GMT and everything seems to be working properly as near as I can tell. Thanks! At 5:44 PM -0700 4/23/05, Wayne Davison wrote: On Sat, Apr 23, 2005 at 06:46:23PM -0500, Raphael Jaffey wrote: Should this be OK or is the most recent "bleeding edge" more stable?

Re: --link-dest / --hard-links problem

On Sat, Apr 23, 2005 at 06:46:23PM -0500, Raphael Jaffey wrote: > Should this be OK or is the most recent "bleeding edge" more stable? The CVS version is more stable than 2.6.4 because it's almost entirely composed of bug fixes (I'm working toward a bug-fix release in the not- too-distant future).

Re: --link-dest / --hard-links problem

Hi Wayne, The patch doesn't just drop in as there's additional code to handle "verbose" mode in the 2.6.4 code which is not in the most recent "nightly" tarball. It looks trival to insert the patch manually. Should this be OK or is the most recent "bleeding edge" more stable? I'm very concerned

Re: --link-dest / --hard-links problem

On Sat, Apr 23, 2005 at 02:01:38PM -0500, Raphael Jaffey wrote: > This can be easily reproduced locally with the following example: Thanks for the test case -- it makes things really easy to fix. Attached is a patch that fixes this bug. It's for the CVS version but it should apply to 2.6.4 as wel

Re: link-dest

On Sat, Jan 15, 2005 at 06:27:03PM +0100, Lars Heer wrote: > I receive following error: > var/run/samba/brlock.tdb > Warning: unexpected read size of -7004 in map_ptr That is weird. I note that some variables in map_ptr() are declared to be "int" instead of "int32", but that won't be the cause of

Re: link-dest

Hi, with rsync-HEAD-20050114-1853GMT I receive following error: var/run/samba/brlock.tdb Warning: unexpected read size of -7004 in map_ptr var/www/dyndns/gallery2/g2data/cache/derivative/8/7/ ERROR during backup for marge at Sat Jan 15 18:25:47 CET 2005 homer:~# I only put the self compiled rsyn

Re: link-dest

On Fri, Jan 14, 2005 at 12:38:59PM +0100, Lars Heer wrote: > Problem for me is that if remotefile exists the link-dest gets not > checked again and I want to be able to pass more than one link-dest > to rsync. You should typically copy into an empty directory tree when using --link-dest to effect

Re: --link-dest doesn't work

On Wed, Sep 29, 2004 at 12:04:21PM -0400, Tony VanScoy wrote: > $ rsync --version > rsync version 2.6.0 protocol version 27 Allow me to answer by reference to things I've said in the past: http://lists.samba.org/archive/rsync/2004-January/008406.html http://www.mail-archive.com/[EMAIL PROTECTED

Re: link-dest doesn't seem to work properly on MacOSX

On Thu, Aug 12, 2004 at 04:23:23AM -0400, [EMAIL PROTECTED] wrote: > it seems to me that the --link-dest option doesn't work properly in my > configuration. Instead of creating hard links for all unchanged files it If the receiving rsync is not running as root, there was a bug in older versions th

Re: --link-dest in man page

On Wed, Jun 16, 2004 at 02:14:32PM -0500, Paul Smith wrote: > The description of --link-dest in the rsync man page should probably > clarify that DIR is, unless it is an absolute path, relative to the > destination directory, not the CWD. This is in the --link-dest description in CVS: Like --

  1   2   >