• The move to the new server is done. There are some software and database maintenance updates in process. This has us passing the hat around to help out. We appreciate any donations. Seriously, even a dollar helps. The payment page may be found here - https://www.audiokarma.org/support.html

Question for the computer guys...

45rpmspinner

45rpmspinner

Super Member
I use Carbon Copy Cloner to handle various backups.
It's a nice program, easy to use, apparently does its job.

One of backups is for the main computer hard drive. A spinner.
It backs up to an external solid state drive once a week.
Creates a mirrored bootable copy, and is set to delete anything on the backup drive that's not longer on the main drive.

But the odd thing is, the main drive shows a total of 139.98 gigs used and the SSD backup shows 336.45 gigs used.
There is no provision made for saving multiple backup versions.

So, the question is, why the difference?

Looks to me like the SSD isn't overwriting deletions.
Any credence to that possibility?
 
Register to hide this ad
painttoad said:
could be stuff in the recycle bin on the ssd.

i will avoid telling you that you would be much happier with an ssd for the main drive and a spinner for the backup drive.
Click to expand...
Oh, that's alright. My other computers use SSDs.

I'm referring to a 10 year old desktop which is still working just fine.
I generally don't fix what isn't broken.

I'm using 7 back-up drives for various things....
I was hoping to swap them all out for SSD just to make for less clutter.
Now I'm thinking maybe that's not such a great idea.
 
Read up on SSDs last night and learned a few things.
Seems that they don't overwrite in the same way that spinners do, which is to say with relative ease.
Actually takes an SSD an extremely long time to overwrite and to the extent that it's forced to so the drive starts to crawl.
In practical terms, you don't want an SSD overwriting.......

Interesting since everywhere I looked there were folks using them for backups.

Used to be that a "Trim" program/action was considered to be essential to SSD health, but less so these days.
Some postulate this is because the price of larger Itb-2tb drives have come down substantially.
The thought being that the more room on the drive the less of a problem overwriting becomes.
All of which is fine except that it implies that grossly oversized SSDs may be necessary.

Which brings me back to my reason for posting.
I thought I had used an oversized SSD for this particular purpose.
500 gig SSD to handle back-up for less than 150 gigs of data sounds like it should do the trick, right?
However, after two years the SSD is filling up.
At the present rate it may not be useable for long.

The reason I checked on it in the first place is because my usual 15 minute backup took over an hour last night.
I'll be using a spinner from now on.

Erasing a SSD in a standard way and re-loading it will apparently do no good.
There are special programs which are supposed to clear SSDs, but it sounds like most are only partially effective.
A report on one program, which apparently works, said it took 6 hours to do the job.

Worth noting that de-fragging an SSD is useless.

From a security standpoint, be aware that your SSD is probably still holding all your data after a standard erase, and is unlikely to be overwritten.
If you're selling your computer, you may want to consider installing a new SSD and physically destroying the old drive.

I'll continue to use SSDs for more or less static archives.
However, I did notice that my music archive is actually 200 gigs larger on the SSD than it is on the spinner I use as double back-up.
The only way I can account for the difference is changes in metadata, perhaps the addition of some artwork, and a relatively small number of deletions.
But I'll keep looking...perhaps there's another reason.
 
Last edited:
I would like to know why "overwrite" is any different from "write." This certainly seems like a technological bait-and-switch in selling the advantages of SSDs.
 
I've been using SSDs a long time, and don't recall any issues regarding performance problems - or at least not as described here in this thread. I wouldn't use them at this point for backups where data is overwritten constantly as there are limited write cycles. I'm not sure of what the limits are - they might be better than they were.

True, there is no point in defragging a SSD.

As to wiping the drive, I encrypt the SSDs I use. From what I've read, it's recommended you delete the encyption key, then delete the content of the drive. I'd then nuke the partition table too, although that would probably be easy enough to recover - but it wouldn't matter so much considering there's no encryption key to access what's on the drive.
 
old_tv_nut said:
I would like to know why "overwrite" is any different from "write."
Click to expand...
As far as I understand it, SSDs are organized as pages and blocks [which contain hundreds of pages].
Deletions only work on the block level.

So, even when a small deletion is made on SSDs, it affects an entire block or blocks.
And following Flash Translation Layer protocol any data in that block after the edit is then written as virgin data elsewhere.
When this happens, the block essentially stays as it was before the "deletion", but all bits are set to 1.
This precludes any in-place overwriting....which is what an HHD does.
Perhaps you can see how that might waste space?

So, what's needed is a space manager for the SSD.
This where TRIM comes in. Theoretically it maps the blocks which can be overwritten and notifies the drive when to do so.
However, TRIM apparently doesn't work with all drives, or has no apparent effect, or sometimes slows the computer to an unacceptable level.
On Macs, the use of TRIM comes with some major cautions, specifically that it may cause data loss or corrupted data.

Newer Mac OS uses a format which is optimized for SSDs.
A space manager called Spaceman is part of the deal.
Some think that the TRIM command doesn't even work anymore.
 
This still seems a bit screwy. If the SSD firmware can mange not to write repeatedly to a particular block, why couldn't it keep track of blocks that have been written to only once and should be the first to be re-used when virgin space runs out? If I understand correctly, your SSD is reporting much more space filled than actually has currently "not erased" data.
 
I'm looking over the partition structure on an MSI Cubi II. Debian is installed. None of that really matters. It's just a list of drives and how they're partitioned on a Linux system.

Frankly, I don't remember what the block sizes were that were common on hard drives. I recall that if you're dealing with a lot of smaller files, you should make your block sizes smaller, It's just not something I muck around with overall. Just no need to.


Code: 
root@msicubi:~# fdisk -l
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: Sabrent Rocket nano                     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xea48a5a5

Device         Boot   Start        End    Sectors   Size Id Type
/dev/nvme0n1p1         2048     999423     997376   487M 83 Linux
/dev/nvme0n1p2      1001470 2000408575 1999407106 953.4G  5 Extended
/dev/nvme0n1p5      1001472 2000408575 1999407104 953.4G 83 Linux


Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/nvme0n1p5_crypt: 953.38 GiB, 1023679660032 bytes, 1999374336 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/msicubi--vg-root: 930.37 GiB, 998974160896 bytes, 1951121408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/msicubi--vg-swap_1: 976 MiB, 1023410176 bytes, 1998848 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdb: 29.16 GiB, 31312576512 bytes, 61157376 sectors
Disk model: Storage Device 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1        8192 61157375 61149184 29.2G  c W95 FAT32 (LBA)
 
45rpmspinner said:
So, the question is, why the difference?
Click to expand...

Maybe you should ask the maker of your back-up software. For example, it could be, that they make use of a "blind copy" strategy for bootable back-ups/images, so that not only the used, but also the unused sectors are copied.

Greetings from Munich!

Manfred / lini
 
lini said:
Maybe you should ask the maker of your back-up software. For example, it could be, that they make use of a "blind copy" strategy for bootable back-ups/images, so that not only the used, but also the unused sectors are copied.

Greetings from Munich!

Manfred / lini
Click to expand...

That's a good idea. I've sent them an email.

I'm not convinced the problem is the SSD itself.
I'm still looking around.

When I get the time today, I'm gonna check the drive for hidden files.
 
You must log in or register to reply here.
Back
Top Bottom