The Unhappy Me thread

[retina]

IMO, with any good backup strategy one should be able to abandon failing disks (since they are now unreliable and can't be trusted, thus obviating the need for data recovery software) and simply put in some new capacity and let the normal backup process copy over the data as part of it's normal operation.

[xilman]

Originally Posted by retina

IMO, with any good backup strategy one should be able to abandon failing disks (since they are now unreliable and can't be trusted, thus obviating the need for data recovery software) and simply put in some new capacity and let the normal backup process copy over the data as part of it's normal operation.

By and large I agree with you.

However, as long as the failing disks are not used for anything new they may as well be kept around as an additional, albeit suspicious, source of old files.

In the present case I'll probably keep the failing disk untouched for a year or so and then use it for storing data for which I have absolutely no qualms about losing the entire damned lot without warning or recourse to recovery.

[mrh]

Originally Posted by xilman

This disk holds the backups for all the other systems. The originals are still in place, AFAIK.

Please don't try to teach me how to suck eggs. I've been taking backups in a professional capacity for over thirty years. How many other people here can read data taken in 1982 and copied from 8" CP/M format floppies all the way through to the current 4TB WD-Red drive? Essentially every email I've sent and received in the last 25 years is still available on live storage. The exceptions are spam and some contents of some publicly available mailing lists. When one of my systems is retired its disk is generally kept for a few years in case I need to use it as a backup. Yes, I do still have 8" floppy drives and a bunch of their disks. I've no idea whether they are still usable without having to go to inordinate trouble.

I've been using RAID systems for about 25 years. That is within 5 years or so of the term being defined. I am well aware that RAID is not in itself a backup solution; it can be a valuable but inessential part of a backup solution. The point of my plan to use RAID for the backup storage is resilience against failure of any one disk in the set which is used to hold the backups.

A backup system has to have a termination condition for the recursion implied by a perceived need to have a backup to use in case a higher-level backup fails. My risk analysis and cost-benefit analysis indicates that a single-level master back-up scheme is appropriate. Within that master are monthly snapshots of each of the component file systems which have been backed up. These snapshots are not backups either; they are archives. Until I run out of disk space, which is essentially never because doubling available storage is a manageable expense, those snapshots are kept "forever".

When the disks have been installed and populated the old 4TB disk will be put into storage for a year or two before being scrapped or reformatted and used for scratch storage of unimportant data. such as images of CDs and DVDs which are difficult to mount in bulk and generally not very fast to access.

I too like to keep all my (useful) e-mail. My oldest online e-mail is from 1987, which is older than some people I work with.

[xilman]

Originally Posted by mrh

I too like to keep all my (useful) e-mail. My oldest online e-mail is from 1987, which is older than some people I work with.

Now there's a challenge! I truly don't know the age of my oldest recorded email. I'll go have a look.

[xilman]

Originally Posted by xilman

Now there's a challenge! I truly don't know the age of my oldest recorded email. I'll go have a look.

A cursory search of the file system shows:

From GMH@UK.AC.RO-GREENWICH.STARLINK Mon Jul 25 20:55:14 1988

As should be obvious, this dates from when JANET was still running Coloured Book rather than IP.

I'm fairly sure that I've fanfold music-ruled hard copy of mail which is at least five years older. Grepping yellowing chewed trees is too inconvenient for me to be bothered right now.

[mrh]

Originally Posted by xilman

Now there's a challenge! I truly don't know the age of my oldest recorded email. I'll go have a look.

I don't think my friend will mind me posting her e-mail address:

From baldasa@nprdc.arpa Fri Oct 23 11:18:35 1987

[xilman]

Originally Posted by chalsall

Please forgive me if I'm telling you how to chew gum, but...

Personally, ddrescue has saved my butt *many* times. Also, I prefer RAID-6 over RAID-5. Nice to have the array fully utilized, rather than simply "hot spare(s)".

I've had to give serious thought about how to transfer the 1.1TB of data to the new disks.

Although I've several terabytes of free space scattered around, the problem is that it is scattered around. No one partition has 1.1TB of free space. I can't just re-image the disk onto a new one because the file systems will be radically different: an ext4 on the old hardware, zfs on the new.

Best I can come up with is to build the zfs file system then ddrescue each partition on the dying disk into regular files within zfs. That will give me two disk images each containing an ext4 partition which can be mounted with "-o loop". From there the files can be copied in the usual manner to a directories in the zfs system --- plenty of room because there will be almost 3TB free --- and the disk images flushed when they are no longer required.

Better alternative solutions are welcomed!

[chalsall]

Originally Posted by xilman

Better alternative solutions are welcomed!

I personally can't think of a better workflow based on your stated constraints.

As ddrescue's inputs and outputs are simply files (which just happen to usually contain filesystems, often immediately above hardware) your proposed methodology should work just fine.

Not meaning to sound flippant here, but I sometimes feel sorry for "Normals", who's only real understanding of how computing works is what they see in their browsers; and their most common interaction is by clicking...

[xilman]

Originally Posted by chalsall

I personally can't think of a better workflow based on your stated constraints.

As ddrescue's inputs and outputs are simply files (which just happen to usually contain filesystems, often immediately above hardware) your proposed methodology should work just fine.

Thanks. That's what I'm doing, though I first forgot to set the-S flag to produce a sparse file. The first partition, of size 200M, takes only 544K on disk.

The other one is now 3.48% done. ETA has varied between 9 hours and 740 days. It's currently at 438 days.

Based on the earlier fsck -c, I'm expecting 48-72 hours.

Edit roughly a minute later: now 9h 35m and 3.70% done

2nd Edit: " ipos: 158813 MB, non-trimmed: 65536 B, current rate: 6553 B/s" Wah! I've seen glass ttys on serial lines go faster than that.

[fivemack]

Originally Posted by fivemack

On Sunday my pile of bargainhardware.co.uk computers stopped responding. Yesterday I noticed that the (rather expensive 10Gbit SFP) switch on top didn't admit to any of its ports being connected; I unplugged the cluster and plugged it in again, and got a loud bang, a bad smell, and tripped the circuit-breaker for the outbuilding and the circuit-breaker for the whole outbuilding on the main distribution board.

And two of the other Linux boxes haven't come back cleanly from the unexpected power cut.

I fear fib(1475) will not be factored as quickly as I was hoping.

I’ve got three machines back (one was waiting for me to press a key to confirm restarting with default BIOS, one came back fine when I plugged computers in one at a time, one had managed to acquire an initrd which couldn’t find the OS disc); down to 1/4 of the BargainHardware machines but £1000 for 80 Sandy Bridge core-years isn’t a bad deal by Amazon standards.

[xilman]

Life is like an alimentary canal. It doesn't matter what you put into it, you only get two things out of it, and one of those is hot air.