我是 GCP 的新手，所以请原谅我的无知。
我有一个运行数据库应用程序的 3 节点 GKE 集群。每个节点都分配了一个 100GB 的标准永久性磁盘。但是，我发现每隔一段时间（自 8 月以来至少发生 3 次）我启动并且数据丢失并且任何已实施的防火墙规则都被重置为默认值。
我可以：
- 阻止数据库中的数据被擦除
- 防止防火墙规则被重置
这是因为基础设施升级吗？
我很难在 Apache Cassandra（版本 3.0.9）上恢复快照。据我所知，我正在遵循 datastax 博客上描述的程序以及其他几个程序（例如：http ://datascale.io/cloning-cassandra-clusters-fast-way/ ）。然而我可能会丢失一些东西，每次我进行恢复时，数据都会丢失。
设置： 6 个节点集群（1 个 DC，3 个机架，每个机架 2 个节点），复制因子设置为 3。机器托管在 AWS 上。
备份程序（在每个节点上）：
nodetool snapshot mykeyspacecqlsh -e 'DESCRIBE KEYSPACE mykeyspace' > /tmp/mykeyspace.cqlnodetool ring | grep "$(ifconfig | awk '/inet /{print $2}' | head -1)" | awk '{print $NF ","}' | xargs > /tmp/tokens
我得到了 nodetool 快照命令生成的文件，并在 S3 上将它们与令牌和 cql 一起备份。
恢复过程（对于每个节点，除非指定）：
（创建新虚拟机后）
- 下载快照、令牌和密钥空间
- 停止服务卡桑德拉
- 删除
/var/lib/cassandra/commitlog/*和/var/lib/cassandra/system/ - 将令牌插入
cassandra.yaml - 启动服务卡桑德拉
mykeyspace.cql仅从一个节点上恢复 mykeyspace- 等待复制并停止服务 cassandra
- 删除
.db文件夹中的文件/var/lib/cassandra/data/mykeyspace/ - 对于每个表，将快照文件 (
.db,.crc32,.txt) 复制到/var/lib/cassandra/data/mykeyspace/$table/ - 重启服务cassandra
- 运行
nodetool repair mykeyspace -full，一次一个节点
结果 ：
总是有缺失的行，每个表的数量大致相同，但绝不是相同的。我试图“混淆”一些过程，比如在令牌之前恢复密钥空间，nodetool refresh在修复之前运行，但我每次都遇到同样的问题。
由于我距离“良好”恢复不远，我认为我遗漏了一些非常明显的东西。分析日志并没有真正帮助，因为它们没有显示任何错误/失败消息。
欢迎任何帮助:) 如果需要，我当然可以提供更多信息。
编辑：没有人？我用 cassandra 版本（3.0.9）更新了这个问题，我一开始就忘记了。我再次尝试恢复，但没有运气。我真的没有更多的想法:(
据我所知，zfs 使用校验和来防止由 bitrot 引起的数据丢失。
但是如果 bitrot 影响校验和的数据会发生什么。那么，zfs 是认为数据已损坏还是认为校验和已损坏？
Thx 4任何答案，
tbol
我有一个客户认为我们的应用程序不断删除它的所有数据。这确实成为他们的一个主要问题。
问题是，不可能是我们。他们不仅丢失了我们的整个数据文件夹（我们将其放置在用户的“我的文档”文件夹中以便于查找），而且丢失了一些本地设置文件，这些文件位于一般用户配置文件中完全不同的位置。
看起来整个用户要么正在重置，要么正在以某种方式与其他地方的更多...空白配置文件同步。
他们在某种虚拟化的 Citrix 来宾操作系统上运行它。
我看到对“组策略文件夹重定向”的引用可以做到这一点......也许是漫游配置文件？
有任何想法吗？
帮助！
Debian 服务器今天早些时候停止响应。硬件重置后，服务器上的数据回滚到几个月前的二月份的状态。这怎么可能？一切，日志，网络数据，数据库，就好像计算机在 03.2 月关闭并在今天打开一样。
有谁知道是什么原因造成的？被黑了？我怎样才能防止这种情况再次发生？
非常感谢！
编辑：
这是真正发生的更新。
服务器上有镜像 RAID 配置。其中一个硬盘在 2 月 3 日停止写入数据。今天早些时候第二个硬盘坏了，系统只能从第一个硬盘启动。这就是为什么所有数据都这么旧的原因。
显然，这是百万分之一的情况。
编辑：
所以你不会遇到和我一样的情况：
http ://www.tcpdump.com/kb/os/linux/raid-alerting.html
听起来很尴尬我设法将 debian iso 添加到外部硬盘而不是我的 USB 笔式驱动器。
现在我的 1.5 TB western digital 有 1 个 700mb 的分区，名为 debian，其余的是未分配的空间。
如果我正确理解 dd 的工作原理，光盘中的前 700mb 数据会丢失，因为它们已被覆盖。
有什么办法可以挽救剩下的吗？
//磁盘是ntfs分区的
使用 DRBD 版本：8.2.6 (api:88/proto:86-88)
这是 /etc/ha.d/haresources 的内容
db1 192.168.100.200/24/eth0 drbddisk::mysql 文件系统::/dev/drbd0::/drbd::ext3::defaults mysql
和 /etc/ha.d/ha.cf
日志文件 /var/log/ha-log
本地日志设施0
保活 1
死区时间 30
警告时间 10
初始化死机 120
端口 694
bcast eth0, eth4
auto_failback 关闭
节点 db1
节点 db2
重生 hacluster /usr/lib64/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster
死神 5
在测试机器之间的故障转移时，我在 db2 上运行了以下命令：
服务心跳停止
服务 mysqld 停止
drbdadm 关闭 mysql
服务 drbd 停止
db1 上的 /proc/drbd 报告
0: cs:Connected st:Primary/Unknown ds:UpToDate/DUnknown C r---
接下来发生了什么，之后：
- 使服务在 db2 上重新联机
- 使用 hb_primary 脚本将主数据库传输到 db2
- 如上所述取下db1
- 使服务在 db1 上重新联机
- 使用 hb_primary 脚本将主节点转移回 db1
是 db1 重新挂载了 DRBD 磁盘，假设了正确的 IP 并启动了 MySQL。有大量的 MySQL 表损坏；这一切都可以修复（使用 InnoDB 恢复模式 6、mysqlcheck 和偶尔的备份），但它是如何发生的呢？
我推测：
- DRBD 在 MySQL 使用磁盘时断开了磁盘与文件系统的连接，因为干净的 MySQL 关闭不会导致数据损坏
- 心跳控制DRBD，停止心跳服务“拔掉”DRBD
- 在实际故障转移的情况下，这可能会再次发生（由于心跳 ping 超时）
我有一段时间无法再次访问此设置，并想重复测试。
配置设置是否正确？
损坏是我手动测试的结果吗？
有没有比停止心跳服务并让它运行 haresources 命令更好的方法来测试故障转移？