izhmike

Автор легко отделался, я понял что пора менять счетчик по тому, что он насчитал в 7 раз больший объем, счетчик у меня тоже Гранд, только 1.6, к сожалению механический счетчик(даже малогабаритный) у меня без переварки трубы не установить(от осевой трубы до стены 2.5 сантиметра), я решил не заморачиваться, и купил новый счётчик СГМБ-1.6, в принципе тот же гранд, но с возможностью замены батареи.

Но речь не о новом, а о старом счетчике(проработал 6 с половиной лет), как выяснилось разница в конструкции между моделями 1.6 и 4 есть, и видна невооруженным взглядом.

Как видно счетчик ещё показывает циферки, и вроде как все хорошо.

Внутри достаточно много свободного места, пустой как барабан.

Интересно, если бы поставили батарейку посерьезнее(14505 это пальчиковая батарейка), сколько бы он проработал, как уже написал выше, свободного места там еще штуки 3 таких войдут.

Внутри счетной камеры никаких моторчиков, провода идут только к пъезоэлементу.

Продолжаем раскручивать, сразу под элементом, лабиринт

И достаточно затейливый

Газ входит в лабиринт через круглое отверстие, и выходит из него в прямоугольное(ну почти), интересно кто рассчитывал этот лабиринт, и какими методами.

Ну и собственно сам считающий элемент, корявость сборки видна невооруженным глазом, но может это никак и не влияет, и может быть нормой.

На этом у меня все.

P.S.

Интересно, сколько проработает новый счетчик.

Коснемся темы бекапа, вроде простой вопрос но как много но..

Мне совсем не понравились ответы на эти вопросы, к сожалению очень похоже на презентацию систем хранения,

---

В: Необходимо сделать резервное копирование неких данных. Что бы Вы использовали? Как сделать дёшево и как правильно?

О: Самое простое и дешевое решение это архивация неких данных и вынос на внешний носитель. Для работы с обычными файлами этот метод вполне рабочий. А вот для копирования баз данных, особенно больших и нагруженных, такой метод не подходит. Всё дело в том, что между началом копирования и завершением проходит достаточно много изменений в базе и на выходе получается не консистентный бекап. В таких случаях используется логирование действий для последующей «догонки» базы до актуального состояния. Например в psql для этого используется WAL, у oracle это FRA и т.д., но это уже в зоне ответственности администратора баз данных. Виртуальные машины можно бекапить снапшотами с ротацией и выносом их на другой носитель.

В+: А более «взрослые» решения?

О+: Для этого есть масса программно-аппаратных комплексов. Обычно это некий софт, под управлением которого работают дисковые массивы с дедупликацией, компрессией и репликацией. Для наиболее холодных или наиболее разностных данных используются ленточные библиотеки.

---

В общем случае, следуя ответам, получим на выходе набор байт а не бекап.

Задача бекапирования на самом деле намного сложнее.

Представьте что у вас файловое хранилище на несколько десятков терабайт, и туда идет запись 7*24, причем записываемые файлики размеров гигабайт по 5-10.

Взрослые решения являются взрослыми из за цены, недавно на HPE day это обсуждали, нормального бекапа все равно не получается, к сожалению оркестраторы не всегда возможно использовать, а иногда они просто не в состоянии помочь.

Бекап это то что позволяет восстановить доступ доступ к сервису, в наикратчайшие сроки(этим в основном и определяется стоимость решения), и вообще его надо делить на три части:

- оперативный(восстановление после программных сбоев или неверных действий пользователей);

- аварийный(восстановление после выхода из строя оборудования);

- архив(восстановление данных после уничтожения оборудования без возможности его восстановления или приобретения идентичного, так же касается разного специфического софта).

Каждый из видов делается независимо и по разным расписаниям, но тут могут быть варианты, например аварийный снимать с оперативного и так далее, тут зависит от возможностей софта хранящего данные.