On 12/01/18 12:15 PM, David T-G wrote:
Anton, et al --
...and then Anton Aylward said... % % On 12/01/18 11:25 AM, David T-G wrote: % > % > ...and then Anton Aylward said... % > % % > % Since the dummy directory is on new (temporary, 'throw-away') partition and the % > % sources are from a variety of partitions, no, it has to be symlinks. % > % > Wait ... Why would the scratch area have to be on a separate partition? ... % % Go back and read what I said as 'specification'
I see only four other messages from you in this thread, and 'specification'
Take that as 'description'
is not in any of them, so I don't think I've missed a direct quote. In your original email you proposed a dummy dir (tree?) of symlinks but also said that you weren't too happy with that idea.
You missed out a bit. You missed out -- generating the list according to 'whatever' criteria using FIND -- using K3B pointed to the dummy dir with the symlinks and telling it to follow the symlinks which might have odd side effects if the symlinks cascade
% ... % But if you go back you'll also see mention of scatter-gather. % Hard links have to be on the same file system' symlinks can cross file systems.
Yeah, but aren't you the guy who has all 5G volumes so that each fits on a disc, and so doesn't it make sense to write your script tackle a volume at a time with the local "scratch backup" dir right there? That makes the script more general anyway.
Are you proposing a system whereby each of the "5G" partitions has its own dummy dir with symlinks that pertain ONLY to the FS on that partition, generate them all and point k3B at *all* of those dummy dirs: for each mounted file system in $LIST create $FSROOT/dummy_dir find $FSROOT --criteria | \ build sylinks list in $FSROOT/dummy_dir done k3b $( for each mounted file system in $LIST echo $FSROOT/dummy_dir done ) That assumes the whole will fit on a single DVD. But it still leaves me with the issue of .... Oh, wait, they don't have to by symlinks any more! They are all links on the same FS :-)
One nice thing about taking every volume individually is that when one contains so many changes that it would overflow the incremental backup past a single DVD you could then fire off a full backup of just that volume and thus exclude it from the incrementals. Eventually you'd probably settle down to a fluid mix of full backups and a catch-all incremental and just not have to worry about the specifics of what's going on. [I'd be sure to set some timeout per volume, too, so that you are guaranteed a fresh full every so often.]
The reason for the 5G partitions was so that I could do a full backup of the whole of the FS on that partition to a single DVD. If that was all I wanted to do then yes, I could back up the whole thing. But, as an example case, I have the "ByYear" photograph for more than a decade. in one month I may alter a scattered set across that decade. I don't want to have to make 10 full DVD backups if there is just one file changed. If this was a BtrFS rather than a ReiserFS or JFS then I could have snapper see the single change and there would be the single entry in the .snapper tree. The whole point of this exercise if to backup ONLY the changes. That's where FIND came into it. Well, OK, with FIND I can use other criteria. - I could back up only certain sidebar files - I could archive only the changed or newly produced JPGs With a bit of sophistication, I suppose, I could backup based on an EXIF field of the photographs. Tat will take some experimentation :-P -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org