On 9/30/24 09:39, Default User wrote:
Hi!
On a thread at another mailing list, someone mentioned that they, each
day, alternate doing backups between two external usb drives. That got
me to thinking (which is always dangerous) . . .
I have a full backup on usb external drive A, "refreshed" dail
On Mon, Sep 30, 2024, 10:46 AM Joe wrote:
>
> > Is that as good as mutt for viewing this list, ?
>
> It's been fine for the mailing lists, I haven't needed to use any
> archives. I do use mutt on my server as that doesn't have graphics, but
> not very often. As far as email goes, I use a local SM
On 30 Sep 2024 13:12 -0400, from hunguponcont...@gmail.com (Default User):
>> Having both drives connected and spinning simultaneusly creates a
>> window of opportunity for some nasty ransomware (or a software bug,
>> mistake, power surge, whatever) to destroy both backups.
Also why I would not wa
On 30 Sep 2024 19:28 +0100, from debianu...@woodall.me.uk (Tim Woodall):
> On a slight tangent, how does rsnapshot deal with ext4 uninited extents?
However rsync does.
For the actual file copying, rsnapshot largely just delegates to rsync
with --link-dest. Looks like at least the Debian packaged
On Mon Sep 30, 2024 at 5:39 PM BST, Default User wrote:
> So, is there a consensus on which would be better:
> 1) continue to "mirror" drive A to drive B?
> or,
> 2) alternate backups daily between drives A and B?
I'd go for (B), especially if you're continuing to do daily backups, so
the oldest
On Mon, 30 Sep 2024, Default User wrote:
Hi!
On a thread at another mailing list, someone mentioned that they, each
day, alternate doing backups between two external usb drives. That got
me to thinking (which is always dangerous) . . .
I have a full backup on usb external drive A, "refreshed"
On Mon, 2024-09-30 at 19:54 +0300, Henrik Ahlgren wrote:
> On Mon, 2024-09-30 at 12:39 -0400, Default User wrote:
> > But of course, any errors on drive A propagate daily to drive B.
>
> Having both drives connected and spinning simultaneusly creates a
> window of opportunity for some nasty ranso
On Mon, 2024-09-30 at 12:39 -0400, Default User wrote:
> But of course, any errors on drive A propagate daily to drive B.
Having both drives connected and spinning simultaneusly creates a
window of opportunity for some nasty ransomware (or a software bug,
mistake, power surge, whatever) to destro
Hi!
On a thread at another mailing list, someone mentioned that they, each
day, alternate doing backups between two external usb drives. That got
me to thinking (which is always dangerous) . . .
I have a full backup on usb external drive A, "refreshed" daily using
rsnapshot. Then, every day, I
Hi,
Le 30/09/2024, Boyan Penkov a écrit:
> -- If I have multiple drives, do I modify the script to have multiple
> efi2, efi3, ..., efiX ?
I think yes.
> -- it seems that the script above privileges /boot/efi over /boot/efi2
> -- in this case, if /boot/efi becomes corrupted, won't this just co
On Sat, 28 Sep 2024, Michael Kjörling wrote:
On 28 Sep 2024 16:28 +0100, from debianu...@woodall.me.uk (Tim Woodall):
Hmmm, I've managed to fix it. The problem seems to be related to using
echo in the exit trap itself while both stderr and stdout are redirected
- e.g. via |& tee log
If I chang
On Mon, Sep 30, 2024, 3:21 AM Joe wrote:
>
> I use Claws-Mail and leave the HTML module turned off, so I certainly
> can see it.
Is that as good as mutt for viewing this list, especially archived posts?
I use a phone for email only if I'm away from home. I can
> see it in K9 on a Samsung phon
Hello folks,
Thanks kindly -- and my apologies for picking this up after a while;
fell sick here...
A few questions:
-- If I have multiple drives, do I modify the script to have multiple
efi2, efi3, ..., efiX ?
-- it seems that the script above privileges /boot/efi over /boot/efi2
-- in this ca
On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
> Tim Woodall writes:
>
> > However on trying to debug something else, I wanted to run it like this:
> >
> > ./script |& tee log
> >
> > and now it doesn't clean up if I it.
>
> Just a point here about tee since I didn't see anyone else
Tim Woodall writes:
> However on trying to debug something else, I wanted to run it like this:
>
> ./script |& tee log
>
> and now it doesn't clean up if I it.
Just a point here about tee since I didn't see anyone else mention
it. tee has had the -i option to ignore interrupt signals for ages.
15 matches
Mail list logo
