movq
www.uninformativ.de
 (2d ago)
↳ In-reply-to » @mckinley Yes, over 20 years ago, a hard disk died. Not completely, only some parts of it, but it was enough to destroy ~30 GB or something like that.

(That hard disk was in a Windows box and there was no such thing as RAID or anything similar. Didn’t have the money for fancy stuff anyway.)

⤋ Read More
movq
www.uninformativ.de
 (2d ago)
↳ In-reply-to » QOTD: Have you ever suffered significant data loss? If so, what went wrong?

@mckinley@twtxt.net Yes, over 20 years ago, a hard disk died. Not completely, only some parts of it, but it was enough to destroy ~30 GB or something like that.

I bought a lot of DVDs over time and many of them have become unreadable. Star Trek DS9 is among the victims, parts of TNG, parts of X-Files. Really annoying. I didn’t have the required disk space to make backups and, honestly, didn’t think they would die so quickly. When/if I buy movies these days, I either make a backup right away or I treat those DVDs as “will die soon”. 🫤

CDs regularly die, too, although not as often as DVDs.

And of course, lots of floppy disks are dead now. 😂🫤

⤋ Read More
lyse
lyse.isobeef.org
 (2d ago)
↳ In-reply-to » QOTD: Have you ever suffered significant data loss? If so, what went wrong?

@mckinley@twtxt.net When typesetting our graduation newspaper (“Abizeitung” as we call it), I destroyed the work of a whole day. :-D

I plugged in the USB stick of my mate (exact same model as mine) to do a backup of that day’s work. Since mine was already plugged in, the mount path /media/USB_DISK or whatever it was already existed. Throughout the day I saved everything on my drive (I don’t know the reason for that anymore). The newly plugged in thumb drive then got automatically mounted by Konqueror as /media/USB_DISK2 or something like that. I wanted to show off my other mate how cool Linux was and how quickly the command line was able to get things done. By force of habit I cded into the wrong path to first rm -rf *, so that there was room for the new stuff. Indeed, the data was ruined super quickly.

When I noticed my fuckup I aborted immediately, but it was already too late. I went to the family computer to research recovery tools. All the files I was able to restore were corrupted. The Scribus XML files ended somewhere in the middle. So then we decided to redo all the work instead of wasting more time trying to fill in the missing XML. Unsurprisingly, it turned out that not only the last closing tags were missing, much more of the contents disappeared. I remember that I gladly noticed the second typesetting round went much faster. :-)

I could be totally wrong here, but I think one problem was that write operations to external devices were not immediately synced, one had to expicitly flush the write cache, e.g. by umounting it properly. Early on in the typesetting process we decided to have each page or spread as separate *.sla, because a) our computers were not powerful enough to handle a large project and b) once the layout template was cast in stone, we could easily work in parallel and join everything in the end. That helped to limit the damage to just my work. My mate’s was still there I believe.

Oh yeah, that’s certainly the best strategy, @bender@twtxt.net! ;-)

⤋ Read More
mckinley
twtxt.net
 (2d ago)
↳ In-reply-to » @prologic ZFS is fine but it's out-of-tree and extremely inflexible. If Btrfs RAID5/6 was reliable it would be fantastic. Add and remove drives at will, mix different sizes. I hear it's mostly okay as long as you mirror the metadata (RAID1), scrub frequently, and don't hammer it with too many random reads and writes. However, there are serious performance penalties when running scrubs on the full array and random reads and writes are the entire purpose of a filesystem.

@prologic@twtxt.net Planning it ahead of time is all well and good if you have the money to buy 6 or 8 hard drives at once. I really don’t, and I want to mirror the whole thing offsite anyway. Mergerfs will let me do it now, and I’ll buy a drive each for SnapRAID in short order.

⤋ Read More