3 ms·

I guess if you are in the business of selling services that include custom domains that isn't quite as crazy as it initially sounds... You are, of course, assu

I guess if you are in the business of selling services that include custom domains that isn't quite as crazy as it initially sounds... You are, of course, assuming they have a backup and the backup can actually be restored and that the restore contains the required information.

WJW 6y ago
It does say in the original post that: > Our backups are fucked. So I assume that they have already tried and they didn't work.
- arethuza 6y ago
  Early in my career (>30 years) ago I nuked a companies salary database (a missing $ in a shell script moved everything to the file i) No problem they said - we have backups. They had three tapes. First tape failed. Second tape failed. Third tape worked. In retrospect that was a useful, if rather stressful, lesson.
  - lupire 6y ago
    > nuked a companies salary database > a missing $ Bravo!
  - artursapek 6y ago
    >a missing $ in a shell script moved everything to the file i I've always had anxiety when running a shell script, this is a perfect example of why
    - noisy_boy 6y ago
      I always wrap the actual cp/mv/rm etc in echo first before actually running it e.g. running echo "mv $src i" first would have immediately highlighted the problem visually.
  - ansible 6y ago
    It is also helpful to have at least two tape drives, and check the backup tapes against both. Early in my career, we had a storm that caused an electrical surge. In spite of the power protection, it damaged the tape drive on the main server (unknown to us at the time). The entire rest of the system (CPU, RAM, hard drives (RLL!)) were fine. Listening to the backups being run, I noticed it sounded a little different. Eventually I determined that the tape drive (old QIC, maybe 40MB capacity?) worked, but it would not switch tracks when reading / writing. So the backup ran, but it just overwrite the same track rather than write to subsequent tracks. A short backup / restore wouldn't have caught the problem, it was necessary to try to read the whole backup to see. This wasn't caught for a while, so all the backups were mostly useless.

WJW 6y ago

It does say in the original post that: > Our backups are fucked. So I assume that they have already tried and they didn't work.

arethuza 6y ago
Early in my career (>30 years) ago I nuked a companies salary database (a missing $ in a shell script moved everything to the file i) No problem they said - we have backups. They had three tapes. First tape failed. Second tape failed. Third tape worked. In retrospect that was a useful, if rather stressful, lesson.
- lupire 6y ago
  > nuked a companies salary database > a missing $ Bravo!
- artursapek 6y ago
  >a missing $ in a shell script moved everything to the file i I've always had anxiety when running a shell script, this is a perfect example of why
  - noisy_boy 6y ago
    I always wrap the actual cp/mv/rm etc in echo first before actually running it e.g. running echo "mv $src i" first would have immediately highlighted the problem visually.
- ansible 6y ago
  It is also helpful to have at least two tape drives, and check the backup tapes against both. Early in my career, we had a storm that caused an electrical surge. In spite of the power protection, it damaged the tape drive on the main server (unknown to us at the time). The entire rest of the system (CPU, RAM, hard drives (RLL!)) were fine. Listening to the backups being run, I noticed it sounded a little different. Eventually I determined that the tape drive (old QIC, maybe 40MB capacity?) worked, but it would not switch tracks when reading / writing. So the backup ran, but it just overwrite the same track rather than write to subsequent tracks. A short backup / restore wouldn't have caught the problem, it was necessary to try to read the whole backup to see. This wasn't caught for a while, so all the backups were mostly useless.