[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)



hw writes:

On Fri, 2022-11-11 at 21:26 +0100, Linux-Fan wrote:
> hw writes:
>
> > On Thu, 2022-11-10 at 23:05 -0500, Michael Stone wrote:
> > > On Thu, Nov 10, 2022 at 06:55:27PM +0100, hw wrote:
> > > > On Thu, 2022-11-10 at 11:57 -0500, Michael Stone wrote:
> > > > > On Thu, Nov 10, 2022 at 05:34:32PM +0100, hw wrote:
> > > > > > And mind you, SSDs are *designed to fail* the sooner the more > > > > > > data you write to
> > > > > > them.  They have their uses, maybe even for storage if you're so
> > > > > > desperate, but not for backup storage.
>
> [...]
>
> > Why would anyone use SSDs for backups?  They're way too expensive for > > that.
>
> I actually do this for offsite/portable backups because SSDs are shock 
> resistant (dont lose data when being dropped etc.).

I'd make offsite backups over internet.  If you can afford SSDs for backups,
well, why not.

Yes, I do offsite backup over Internet too. Still, an attacker could possibly delete those from my running system. Not so much for the detached separate portable SSD.

> The most critical thing to acknowledge about using SSDs for backups is > that the data retention time of SSDs (when not powered) is decreasing with each 
> generation.

Do you mean each generation of SSDs or of backups?  What do manufacturers say
how long you can store an SSD on a shelf before the data on it has degraded?

Generations of SSDs.

In the early days, a shelf life in the magnitude of years was claimed. Later on, most datasheets I have seen have been lacking in this regard.

[...]

>  The small (drive size about 240GB) ones I use for backup are much less 
> durable.

You must have quite a lot of them.  That gets really expensive.

Two: I write the new backup to the one I have here, then carry it to the offsite location and take back the old copy from there. I do not these SSD's prices but it weren't expensive units at the time.

>  For one of them, the manufacturer claims 306TBW, the other has 
> 360 TBW specified. I do not currently know how much data I have written to 
> them already. As you can see from the sizes, I backup only a tiny subset > of the data to SSDs i.e. the parts of my data that I consider most critical > (VM images not being among them...).

Is that because you have them around anyway because they were replaced with
larger ones, or did you actually buy them to put backups on them?

I still had them around: I started my backups with 4 GiB CF cards for backup, then quickly upgraded to 16 GiB cards all bought specifically for the backup purposes. Then I upgraded to 32 GB cards. Somewhere around that time I equipped my main system with dual 240 GB SSDs. Later, I upgraded to 2 TB SSDs with the intention to not only run the OS off the SSDs, but also the VMs. By this, I got the small SSDs out, ready to serve the increased need for backup storage since 32 GB CF cards were no longer feasible...

Nowdays, my “important data backup” is still close to the historical 32 GiB limit although slightly above it (it ranges between 36 and 46 GiB or such). There are large amounts of free space on the backup SSDs filled by (1) a live system to facilitate easy restore and (2) additional, less important data (50 GiB or so).
[...]

> > There was no misdiagnosis.  Have you ever had a failed SSD?  They > > usually just disappear.  I've had one exception in which the SDD at

[...]

> Just for the record I recall having observed this once in a very similar 
> fashion. It was back when a typical SSD size was 60 GiB. By now we should 
> mostly be past this “SSD fails early with controller fault” issues. It can 
> still happen and I still expect SSDs to fail with less notice compared to 
> HDDs.

Why did they put bad controllers into the SSDs?

Maybe because the good ones were to expensive at the time? Maybe because the manufacturers were yet to acquire good experience on how to produce them reliably. I can only speculate.

[...]

YMMV
Linux-Fan

öö

Attachment: pgpOA05OKRmTN.pgp
Description: PGP signature


Reply to: