Original Summary

A client had a backup job running every week. During a restore test, we found that the credential export contained fingerprints rather than the actual values the app needed. The platform's interface returned enough information to identify a configured secret, but not to retrieve it. The export script had saved that response as though it could be used to reconnect the services later. The files existed. The values inside them weren't usable credentials. To be clear, these were service credentials, not customer login passwords. User passwords should stay hashed. The recovery process needed a secure way to retrieve or replace the credentials the app's integrations used. We also hit three problems in the recovery instructions: • A database client that was too old for the restore. • A connection address that didn't work from the office network. • Two scripts expecting a file-deletion utility that wasn't installed on the Mac being used. A backup running successfully wouldn't have exposed any of that. If you're the only person looking after a small SaaS, I'd try one restore into a separate environment before adding more automation around the backup job. Keep real emails, payments and webhooks disabled or pointed at test services. Then do something a customer would do. Sign in, open an uploaded file, check that another account can't access it, and test an integration safely. Record anything you had to work out that wasn't in the instructions. Also check where the recovery credentials live. If you need access to the failed environment to retrieve them, you'll get stuck. For anyone who's done a restore drill on their own app, what failed that you hadn't expected?   submitted by   /u/HourMode1351 [link]   [comments]

  • 情报分类：工作与职业机会
  • 分类依据：内容涉及招聘、求职或职业发展
  • 信息来源：Reddit · SaaS
  • 发布时间：2026/9/16 02:09:18