大家好！
前一段时间，我陷入了“苛刻的企业”世界，即在负责存储和备份数据的领域。 更确切地说，在其中。 在此期间，我积累了一些规则，在设计或维修该领域的解决方案时要遵循这些规则。 随着技术的发展，有些已经过时了，有些正在运转。 我决定与您分享。
没有规则3-2-1（没有我经常被提及），也没有一些针对特定情况和其他事物的直接技术。 也许对于大多数阅读本书的人来说，这是基本知识和陈词滥调。 这只是我的少量经验，希望对某人有用。 我要猫。
本地“大小调整”功能
迟早需要获得更多的TB和/或IOPS。 然后调整大小。 通常是毫无意义和残酷的。 因为很少有人会放下RTO的大小要求，通常是为了备份而提出的。 尽管这似乎是任何复杂硬件的明显要求。 即 在确定新设备的大小和形成要求时，出于某种原因，将紧急地将某些内容恢复到您的硬件的备份系统的要求未考虑在内。 有时有些东西很大。 通常，在生产率和空间方面都存在一定的裕度，但是最初的数据恢复表明，对于该设备定义的生命周期来说，这还不够。
在过去的一年中，当数据恢复过程中的瓶颈是执行恢复的磁盘阵列时，我已经见过两次情况。 它们适合RTO，但铃声令人震惊。
我们在群集上有一个解决方案，为什么您需要备份？
我在交流时听到的就是这个非常“充满活力”的口语
与开发一种非常有用的软件的企业合作。 开发人员认为，由于解决方案已部署在群集上，因此备份对于恢复是不必要的，因此，如果节点（或磁盘阵列）位于站点上，则群集将保存。 在这些情况下，他无疑会保存下来。 当有些人甚至在开发阶段就考虑容错能力时，这通常非常好。
但是，不仅由于一个站点上的设备故障而导致数据丢失，而且由于某种原因，开发人员不想在一段时间内了解这一点。 结果，该软件的第一版在社区DBMS上发布，其备份机制无法满足RTO / RPO要求或承包商的SLA。
总的来说，我经常听到有关集群的短语。
首先，然后这个！
我最大的错误之一是将备份对象视为独立的对象。 这是DBMS，这是软件。 这样的备份，就是这样。 第一个，然后另一个。 有一天我们无法恢复。 更准确地说，它们可以，但是花了几天的时间来修复数据库中的错误。 不是我淘汰了他们，对此我尤其感到ham愧。 尽管我们为此DBMS使用了常规备份机制。 已经在其他系统上进行过测试。
从那一刻起，我就如何正确备份和还原问题动摇了鼻子，动摇了系统的开发人员/所有者。 例如，在一种情况下，创建有效备份的唯一方法是完全停止5台服务器上的服务，进行备份并启动服务。
倾倒我们的一切？
我经常遇到MySQL和PostgreSQL等DBMS解决方案。 而且，我更经常遇到这样一种情况：将/ tmp中数据库的常规转储用作备份方法，然后再备份至另一种介质。 同时，使用这些DBMS的系统在数据丢失的情况下对于停机至关重要，并且负载非常大。 我已经对音量保持沉默。
由于某些原因，很少有人阅读这些产品的文档，并且不知道还有其他方法和解决方案可用于创建这些DBMS的备份。 在PostgreSQL中分别用于MySQL和
pg_basebackup （
pg_start_backup，pg_stop_backup ）的
MySQL企业备份 。 或者他知道，但是飞出了头。 尽管这些解决方案并没有那么复杂和快速。 更快的备份，更快的还原，更快的测试。
请不要射击钢琴家。
他正在尽力而为。
奥斯卡·芬加（Oscar Fingal）欧弗拉赫蒂（W'Flahertie）威尔斯·王尔德（Wills Wilde）