Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 26 27 28 29 [30] 31 32
[#] Sat Jul 02 2022 14:40:14 UTC from zelgomer

Subject: Re: Remote storage client-side encryption recommendations?

[Reply] [ReplyQuoted] [Headers] [Print]

2022-07-01 22:46 from darknetuser <darknetuser@uncensored.citadel.org>

Subject: Re: Remote storage client-side encryption recommendations?
What do you guys use for personal off-site backup? My requirements

are

something between 50-100GB, client-side encrypted, infrequent access



(only need to update it maybe once or twice a month). I just want to



satisfy the "-1" part of the "3-2-1" rule--3 backups, 2 local on

separate media and 1 off-site. The problem is that it includes
sensitive personal information, hence I want client-side encryption.





For non system files or files that are not going to change during
backup, then rclone may be workable since it features client-side
encryption. You can use rclone to upload data to any standarized file

storage
service since rclone supports all the popular ones (such as
ftp, sftp, webdav or whatever have you). Maybe you may try it with the

Backbaze backup provider. I ran the numbers back in the day and they
are a bit cheaper than operating your own NAS for small business use.



This rclone looks pretty interesting. Thanks for the tip!

[#] Sat Jul 02 2022 14:43:23 UTC from zelgomer

Subject: Re: Remote storage client-side encryption recommendations?

[Reply] [ReplyQuoted] [Headers] [Print]

2022-07-02 01:02 from Nurb432 <nurb432@uncensored.citadel.org>
Subject: Re: Remote storage client-side encryption recommendations?
Random thought. Something like ipfs might work too. 
( https://ipfs.io/ )   


I have thought of that, too, though I haven't played with ipfs so I don't feel like I understand it well enough. Part of the "life story" that I keep trying not to bring up because, ultimately, it is boring and irrelevant, is that I have a long history of trying to use Tahoe-LAFS for this purpose. darknetuser has heard some of my beefs with Tahoe-LAFS, but to summarize it, I have concluded that if your goal is really backup, then you must be able to know and control where it goes; otherwise you are just rolling the dice on whether or not it will be available when you need it.

[#] Sat Jul 02 2022 16:19:55 UTC from Nurb432

Subject: Re: Remote storage client-side encryption recommendations?

[Reply] [ReplyQuoted] [Headers] [Print]

Right, the best solution is in your grubby little hands.

But having a plan B, never hurt.

 



[#] Mon Jul 11 2022 12:34:28 UTC from IGnatius T Foobar

Subject: Re: Remote storage client-side encryption recommendations?

[Reply] [ReplyQuoted] [Headers] [Print]

I have a computer at home and another at a data center and they back up to each other. Some of the backups are rotated using daily btrfs snapshots (thin clones for the win). The data center is about 12 miles from my house. I figure if anything destroys both sites it probably destroyed me as well ... and I'm ok with that.

[#] Mon Jul 11 2022 16:00:52 UTC from LadySerenaKitty

Subject: Re: Remote storage client-side encryption recommendations?

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mon Jul 11 2022 08:34:28 EDT from IGnatius T Foobar Subject: Re: Remote storage client-side encryption recommendations?
I have a computer at home and another at a data center and they back up to each other. Some of the backups are rotated using daily btrfs snapshots (thin clones for the win). The data center is about 12 miles from my house. I figure if anything destroys both sites it probably destroyed me as well ... and I'm ok with that.

Alternatively, you could use tarsnap, tho I'm not sure if it's available for linux.  With ZFS, you can use the snapshot scripts and then "zfs send" to send snaps across a network (with "zfs recv" on the other end).  Alternatively, you can locally attach a remote ZFS pool and mirror them, for effortless continuous backups.



[#] Tue Jul 12 2022 08:38:16 UTC from darknetuser

Subject: Re: Remote storage client-side encryption recommendations?

[Reply] [ReplyQuoted] [Headers] [Print]

2022-07-11 12:00 from LadySerenaKitty
Subject: Re: Remote storage client-side encryption recommendations?
 
Mon Jul 11 2022 08:34:28 EDT from IGnatius T Foobar Subject: Re:
Remote storage client-side encryption recommendations?

I have a computer at home and another at a data center and they
back up to each other. Some of the backups are rotated using daily
btrfs snapshots (thin clones for the win). The data center is about
12 miles from my house. I figure if anything destroys both sites it
probably destroyed me as well ... and I'm ok with that.







Alternatively, you could use tarsnap, tho I'm not sure if it's
available for linux.  With ZFS, you can use the snapshot scripts and
then "zfs send" to send snaps across a network (with "zfs recv" on
the other end).  Alternatively,
you can locally attach a remote ZFS
pool and mirror them, for effortless continuous backups.


I think tarsnap is available for Linux. The problem is that, last time I researched into it, the price was not great. I'd rather use Backblaze's bussiness plans with rclone if I didn't want to use my own server and speed of recovery was not critical.

[#] Sun Jul 17 2022 21:22:32 UTC from IGnatius T Foobar

Subject: Re: Remote storage client-side encryption recommendations?

[Reply] [ReplyQuoted] [Headers] [Print]

the other end).  Alternatively, you can locally attach a remote ZFS
pool and mirror them, for effortless continuous backups.

That sounds pretty cool, actually. And kudos to the BSD people for keeping ZFS alive even after the collapse of Sun and Solaris.

Filesystems with built in snapshot capability have been such a big blessing for backups. In the old days we had to do horrifying things like taking database replicas offline so we could back them up in a crash-consistent state, and then catch up the replica afterwards.

[#] Fri Aug 26 2022 13:23:58 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


Anyone going to re:Invent this year? My continued foray into multi-cloud has resulted in me getting sent there to help out with our booth and to explore the conference itself. This will be my first time at an AWS event and my first time going to the state of Nevada.

If anyone else is going let me know and we can arrange to meet.

[#] Fri Aug 26 2022 14:51:38 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Hadn't planned to go, and don't have a strong need to go, but maybe I could cop an excuse to go.

[#] Fri Aug 26 2022 20:17:36 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

never heard of it.  what is it, where is it  ( ya ya i know.. 'google' )



[#] Fri Aug 26 2022 20:20:44 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

wow i cant read apparently. ignore me.

 

( was trying to read on a phone sized screen.  ill stop that )

Fri Aug 26 2022 04:17:36 PM EDT from Nurb432

never heard of it.  what is it, where is it  ( ya ya i know.. 'google' )



 



[#] Sun Aug 28 2022 15:02:01 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Yeah. I'm doing a lot of multi-cloud and hybrid-cloud stuff these days, and over the next couple of years I'm going to be replacing a lot of dead wood with Terraform scripts. We have a lot of customers who want to spread their workloads across two or more cloud providers. Somehow I ended up being one of the privileged few who gets to work on *everything* ... it's a real blessing to be able to expand my horizon like this without having to get a new job.

I was asked whether I wanted to focus more on AWS or Azure. I'll be focusing on AWS of course. And I've got to say, after being aligned with underdogs for my whole career, it's really weird to be building up skills to work with the industry top dog. Yes, I still think they're too big and should be broken up (using bombs). But I guess at this point in my life I don't have the energy to play the underdog game again.

It's all Linux. We have to go through all sorts of weird contortions to make our laptops work with cloud native tools, which all run on Linux. At some point we're going to have to lobby the IT department to let us just run Linux on the bare metal. I love that Linux won. We won everything. The last dinosaur only controls the end user desktop now and it doesn't even matter much. I'm going to spend the next 20 years enjoying that instead of being a revolutionary again.

So yeah, I'm going to re:Invent this year. It's going to be weird. And I'm not going to allow anyone to scan my badge because the last thing I need is a new influx of spam and phone calls. Booth vendors aren't supposed to sell their lists but they do.

(For those who don't recognize the "last dinosaur" reference -- obviously I'm talking about M$ but there's a paper called "The Last Dinosaur and the Tarpits of Doom" written by Jeff Prothero in 1999 in which he predicted the decline of Windows and the inevitable dominance of Linux. His predicted timeline was off by decades but the general idea seems to have held up. Jeff was also the original developer of Citadel on a CP/M system in 1981. Sometimes he was really smart. Sometimes he was really stupid. But he got this one right, sort of.)

[#] Sun Aug 28 2022 15:39:34 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Not being an infrastructure person now, and that my main app was migrated away from AWS ( performance and support reasons. i guess things like an SQL server really isn't and its something else.. ) no way i can pull off going.

 

But hey, if the ITSM foundation folks ever have another conference in person, ill most likely get to go.  Tho by the time that happens i may be gone. 



[#] Tue Aug 30 2022 20:05:29 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

It's all Linux. We have to go through all sorts of weird contortions

to make our laptops work with cloud native tools, which all run on
Linux. At some point we're going to have to lobby the IT department to

let us just run Linux on the bare metal. I love that Linux won. We

WSL2 is fast these days, but brittle (crashy GUI, last time I evaluated that) and the GUI lacks some window management features like snap-to-half-screen; it's more of a basic X server type of deal.

The biggest thing to beware of is that if you fuck up your bashrc you render the entire thing unbootable and there is no recourse! It must be reinstalled from scratch!

[#] Tue Aug 30 2022 20:06:35 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


and WSL2 doesn't run systemd, which sounds like a good thing until you realize all the bizarre hacks you have to do in its absense these days. e.g. it's possible to run docker, but those normally want to run dockerd and containerd under systemd and you need some painful-to-configure hacks

[#] Wed Aug 31 2022 16:00:49 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

WSL2 is quite nice if you're stuck on Windows and need to run Linux developer tools. My consternation is with the Cisco Anyconnect VPN and our IT department who refuses to change the configuration to allow WSL2 to work properly with it.

There's a site where you can download some fugly PowerShell scripts to tweak all of the adapter settings, and you have to install half a dozen Scheduler events to make those scripts run when the VPN activates and deactivates, when WSL starts up, etc. etc. It works but it's *very* fragile, breaking when pretty much any component (Windows, WSL, AnyConnect) receives an update. One of our developers discovered it today and was annoyed when I rained on his parade, but he'll discover soon enough that it's too fragile to depend on.

If there were some sort of standalone user mode NAT for Windows, that worked like the one built into VirtualBox, I'd love to use that.

[#] Wed Aug 31 2022 22:00:31 UTC from nristen

[Reply] [ReplyQuoted] [Headers] [Print]

I recently ran accross multipass from Canonical. I played with it briefly and it looks interesting. I don't know much about how it integrates with the host's network yet.

[#] Thu Sep 01 2022 16:04:27 UTC from LadySerenaKitty

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Aug 31 2022 18:00:31 EDT from nristen
I recently ran accross multipass from Canonical. I played with it briefly and it looks interesting. I don't know much about how it integrates with the host's network yet.

LEELOO DALLAS MULTIPASS!



[#] Thu Sep 01 2022 20:23:55 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

lol



[#] Tue Sep 06 2022 03:01:01 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

YOU SHALL NOT MULTIPASS!!!!

Go to page: First ... 26 27 28 29 [30] 31 32