On Wed, 2024-01-17 at 10:29 -0800, Kushal Kumaran wrote:
> On Wed, Jan 17 2024 at 11:19:39 AM, Default User
> <hunguponcont...@gmail.com> wrote:
> > Hello!
> >
> > Opinions, please.
> >
> > I use rsync to copy my primary backup drive to a secondary backup
> > drive
> > , so that the secondary backup drive is theoretically always an
> > exact
> > copy of the primary backup drive.
> >
> > Here is the rsync command I use:
> >
> > time sudo rsync -aAXHxvv --delete-after --numeric-ids --
> > info=progress2,stats2,name2 --
> > exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/m
> > edia
> > /*","/lost+found"} /media/default/MSD0001/ /media/default/MSD0002/
> >
> > Question:
> > I use rsync --delete-after because it might seem to be "safer", so
> > in
> > case of a "glitch" of any kind, no file ever disappears from both
> > the
> > source drive and the destination drive.
> >
>
> What do you mean by "glitch"? Irrespective of whether you use --
> delete
> or --delete-after, deleted files on the source are deleted on the
> destination once your rsync is complete (which is what I'd assume you
> want when you want an exact copy). I'd presume if you're ok with
> that,
> you are also fine with the deletion happening earlier in the rsync
> process?
>
> If you're concerned about accidental deletions, you should just not
> use
> any of the `--delete*` options (and give up on the exact copy
> requirement). You can look at alternatives to bare rsync that keep
> track of multiple backed-up images (rsnapshot is a very simple
> wrapper
> over rsync that can do this, for example).
>
> > However, I have read that using rsync --delete instead of rsync --
> > delete-after is faster and uses less memory, and so is more
> > efficient.
> >
> > Note: The current copy process time varies, but takes a long time -
> > last night 131 minutes.
> > :(
>
> You can try using --delete for a couple of runs and see if it
> actually
> affects performance in your situation.
>
> >
> > Disk space used is not currently an issue.
> >
> > But, is rsync --delete AS SAFE as rsync --delete-after?
>
> You'll need to define what safety means for you.
>
Hi, Kushal!
Thanks for replying.
By "glitch", I mean anything that could interfere with the rsync copy
process. Possible causes:
- electrical outages, voltage spikes, voltage drops, "brownouts"
- mechanical failure
- earthquake
- lightning
- cat walking on keyboard
- out of memory errors
- out of disk space errors
- PEBKAC errors
- etc.
By safe, may I try to explain using a story?
I once read that centuries ago, a king wanted his crown to be safe. So
four guards watched his crown at all times. The guards were not
allowed to take their eves off of the crown, even for a second, until
the the their replacements, the next group of guards, all said "I see
the crown".
I am sorry if I can not come up with a better, technical explanation.
I use this story because it has always been meaningful to me, and seems
to point to the essence of what I am getting at.
I am writing as someone who has lost data more than once over time, for
various reasons. The loss has ranged from slightly annoying, to soul-
rending catastrophe. It is NEVER appreciated.
I do intend to try doing rsync --delete instead of rsync --delete
after, to see if it "seems to work".
But I just wanted to ask first ask, as it would seem better to hear
someone say "How stupid are you? I can't believe you were going to do
that!", than to have them say "How stupid are you? I can't believe you
did that!"
