Клуб строителей домашнего LAN

[SergM]

(29-10-2019 18:27)smile :  цілісність оригіналу чи якісь судження про цілісність оригіналу не є зоною відповідальності процесу бекапа. тому, будь які пошкодження оригінала не є проблемою бекапа.

Але є така штука – сенс бекапа. І вона здається не у тому що сам бекап є

(29-10-2019 18:27)smile :  тобі про що саме повість написати?

Та не треба – то був жарт.
Є звичайні користувачі, яким просто структуровані дані що лише додаються на 1-й рейд – вже норм, але зазвичай там просто купа нерозібраного сміття. А є збоченці у темі, що перемагають інженерною думкою здоровий глузд

[smile]

(30-10-2019 10:33)SergM :  

(29-10-2019 18:27)smile :  цілісність оригіналу чи якісь судження про цілісність оригіналу не є зоною відповідальності процесу бекапа. тому, будь які пошкодження оригінала не є проблемою бекапа.

Але є така штука – сенс бекапа. І вона здається не у тому що сам бекап є

коли виникає необхідність у відновленні з бекапа, а бекапа нема, або він надто старий - то вже нічого нікому не здається. усілякі філософські роздуми про сенс бекапа розчиняються у безмежній бентезі буття.

Цитата:

(29-10-2019 18:27)smile :  тобі про що саме повість написати?

Та не треба – то був жарт.
Є звичайні користувачі, яким просто структуровані дані що лише додаються на 1-й рейд – вже норм, але зазвичай там просто купа нерозібраного сміття. А є збоченці у темі, що перемагають інженерною думкою здоровий глузд

то пан таки недосвідчений. мабуть ніколи не чухав потилицю, дивлячись на розвалений рейд та панічно заглиблюючись у вир здоровоглуздої нірвани зі словами "бля, де бекап?!".



PS. пам'ятаю, був випадок, коли один філософ здоровоглуздо робив бекапи бази даних на той-самий дисковий масив з 10-м рейдом і хот-спаре дисками, де і БД сиділа. а коли накрилось обидва контролера зі втратою конфігурації рейда, то ой яка моторошно дзвінка пауза була після оцього самого питання "бля, де бекап?"

[SergM]

Ну тоді...

(30-10-2019 12:58)smile :  

(30-10-2019 10:33)SergM :  Але є така штука – сенс бекапа. І вона здається не у тому що сам бекап є

коли виникає необхідність у відновленні з бекапа, а бекапа нема, або він надто старий - то вже нічого нікому не здається. усілякі філософські роздуми про сенс бекапа розчиняються у безмежній бентезі буття.

Здається здоровий глузд слів "відновлення з бекапа" передбачає цінність та цілісність збереженої у ньому інформації, бо коли щось пішло не так і від наявного бекапа немає ніякої користі, то залишається лише дзен і інша безмежна філософія.

(30-10-2019 12:58)smile :  то пан таки недосвідчений. мабуть ніколи не чухав потилицю, дивлячись на розвалений рейд та панічно заглиблюючись у вир здоровоглуздої нірвани зі словами "бля, де бекап?!".

Та ні – пан знає що окрім автоматичного бекапу бажано мати ще й ручний на незалежний носій офлайн. Але таки не чухав потилицю, бо уникає такої можливості занурення у нірвану.

(30-10-2019 12:58)smile :  PS. пам'ятаю, був випадок, коли один філософ здоровоглуздо робив бекапи бази даних на той-самий дисковий масив з 10-м рейдом і хот-спаре дисками, де і БД сиділа. а коли накрилось обидва контролера зі втратою конфігурації рейда, то ой яка моторошно дзвінка пауза була після оцього самого питання "бля, де бекап?"

– Той падаван мабуть геть неспроможний відчути силу...

[smile]

(30-10-2019 13:36)SergM :  Здається здоровий глузд слів "відновлення з бекапа" передбачає цінність та цілісність збереженої у ньому інформації, бо коли щось пішло не так і від наявного бекапа немає ніякої користі, то залишається лише дзен і інша безмежна філософія.

ти вгадав всі букви та слова в "інкрементальний бекап", але не вгадав зміст словосполучення. боюсь навіть запропонувати такі слова, як "backup retention policy" або "backup retention strategy".

окай. якщо "інкрементальний бекап" важко осягнути, особливо для папок з домашніми фотками та відео, то спробуй, для них же, осягнути призначення сімейства параметрів --delete* програми rsync, можливо тебе осяє відкриття необов'язковості цих параметрів

Цитата:Та ні – пан знає що окрім автоматичного бекапу бажано мати ще й ручний на незалежний носій офлайн. Але таки не чухав потилицю, бо уникає такої можливості занурення у нірвану.

пан має смак до збочень? пан хоче мати паперовий журнал виконання ручних бекапів, де мають вести записи виконавець та його контролер? з щотижневим аудитом журналу?
пан не чув що по мережі можна не тільки порно про ручні бекапи дивитись, а і інші дані передавати, наприклад бекап на незалежний носій?


PS. спроба зрозуміти "incremental backup retention policy" мабуть тебе просто вб'є.

[SergM]

Якщо пан має час та натхнення...

(30-10-2019 14:00)smile :  

(30-10-2019 13:36)SergM :  Здається здоровий глузд слів "відновлення з бекапа" передбачає цінність та цілісність збереженої у ньому інформації, бо коли щось пішло не так і від наявного бекапа немає ніякої користі, то залишається лише дзен і інша безмежна філософія.

ти вгадав всі букви та слова в "інкрементальний бекап", але не вгадав зміст словосполучення. боюсь навіть запропонувати такі слова, як "backup retention policy" або "backup retention strategy".

Нажаль система бекапу так само має імовірність виходу з ладу, у тому числі – з повною втратою даних, тому його сенс дуже простий – збереження даних. І ми їх захищаємо відповідно до важливості і встановленого рівня безвідмовної роботи / ступеня доступності / часу простою (відновлення працездатності) тощо. Ну і бюджет звісно, бо предбачити все – дорого.

(30-10-2019 14:00)smile :  окай. якщо "інкрементальний бекап" важко осягнути, особливо для папок з домашніми фотками та відео, то спробуй, для них же, осягнути призначення сімейства параметрів --delete* програми rsync, можливо тебе осяє відкриття необов'язковості цих параметрів

?
І шо?
Головне не нарватися на "наразі неможливо відновити вказані файли бо файл попереднього образу недоступний".
Інкрементальний бекап на загал гарне рішення, але якщо дані змінюються, а не просто додаються, то трохи витратно (особливо для любителів смітити). Тому є стандартні опрацьовані сценарії, що підходять до певних типових завдань.

(30-10-2019 14:00)smile :  пан має смак до збочень? пан хоче мати паперовий журнал виконання ручних бекапів, де мають вести записи виконавець та його контролер? з щотижневим аудитом журналу?
пан не чув що по мережі можна не тільки порно про ручні бекапи дивитись, а і інші дані передавати, наприклад бекап на незалежний носій?

От як вище "кейс" про бекап на стрічці курьером з охороною у депозитарій – так не збочення, а оффлайн – хардкор...

Оффлайн дозволяє уникнути певних проблем і буває вимогою...

(30-10-2019 14:00)smile :  PS. спроба зрозуміти "incremental backup retention policy" мабуть тебе просто вб'є.

Та ні – ще живий. А ось [збочень] реалізації можна багато придумати...

[smile]

(30-10-2019 15:36)SergM :  

(30-10-2019 14:00)smile :  ти вгадав всі букви та слова в "інкрементальний бекап", але не вгадав зміст словосполучення. боюсь навіть запропонувати такі слова, як "backup retention policy" або "backup retention strategy".

Нажаль система бекапу так само має імовірність виходу з ладу, у тому числі – з повною втратою даних, тому його сенс дуже простий – збереження даних.

я так і думав, що "backup retention policy" пройде мимо.

Цитата: І ми їх захищаємо відповідно до важливості і встановленого рівня безвідмовної роботи / ступеня доступності / часу простою (відновлення працездатності) тощо. Ну і бюджет звісно, бо предбачити все – дорого.

то до чого були оті всі філософствування про сенс бекапу, якщо мова йшла про автоматичні бекапи папок з домашніми фотками/відео ?

Цитата:От як вище "кейс" про бекап на стрічці курьером з охороною у депозитарій – так не збочення, а оффлайн – хардкор...

це не збочення - це частина процесу забезпечення збереження дуже дорогих даних за будь яких обставин, включаючи метеорити і ядерні бомби. там купа людей приймає участь в процесі, з потрійним перехресним контролем. там ймовірність проблеми людського фактору зведена практично в нуль. не приймай цей кейс за звичайну практику.

а ось в звичайному технологічному процесі - ручний бекап на "флешку" гарантовано приведе до питання "бля, де бекап?". може ще бути лише уточнююче питання - коли саме настане момент спитати "бля, де бекап?". бо людський фактор - це страшна сила.

а просте щотижневе/щоденне носіння стрічки/диску з бекапом з одного офісу в інший - то не "ручний бекап". то такий спосіб remote backup при відсутності технічної чи фінансової можливості його виконувати через канали зв'язку. деякі системи бекапа навіть мають підсистему обліку траспортних носіїв на майданчиках зберігання та іншою логістикою. типово при такій системі remote backup в будь який момент існує мінімум три екземпляри одгного й того ж бекапа.

[SergM]

(30-10-2019 16:27)smile :  я так і думав, що "backup retention policy" пройде мимо.

? Ви гадаєте що є лише певне визначення / реалізація "backup retention policy" чи у Вас є якийсь власний контекст (я не зрозумів жарту)?

(30-10-2019 16:27)smile :  то до чого були оті всі філософствування про сенс бекапу, якщо мова йшла про автоматичні бекапи папок з домашніми фотками/відео ?

Почалося з банального питання і взагалі було трохи жартів по принципу "з гармати по горобцях"...

(30-10-2019 16:27)smile :  це не збочення - це частина процесу забезпечення збереження дуже дорогих даних за будь яких обставин, включаючи метеорити і ядерні бомби. там купа людей приймає участь в процесі, з потрійним перехресним контролем. там ймовірність проблеми людського фактору зведена практично в нуль. не приймай цей кейс за звичайну практику.

І що? А копія на окремий офлайн носій (та ж стрічка чи ще щось) – це збочення? Тут набагато складніше нівелювати людський фактор у вигляді під'єднати / виконати (+перевірка) / від'єднати? – Це просто окрема запобіжна система (також автоматизована), що доповнює автоматичну.

(30-10-2019 16:27)smile :  ручний бекап на "флешку" гарантовано приведе до питання "бля, де бекап?". може ще бути лише уточнююче питання - коли саме настане момент спитати "бля, де бекап?". бо людський фактор - це страшна сила.

Звичайно – хто на відносно малонадійний носій робить бекапи?

(30-10-2019 16:27)smile :  а просте щотижневе/щоденне носіння стрічки/диску з бекапом з одного офісу в інший - то не "ручний бекап". то такий спосіб remote backup при відсутності технічної чи фінансової можливості його виконувати через канали зв'язку. деякі системи бекапа навіть мають підсистему обліку траспортних носіїв на майданчиках зберігання та іншою логістикою. типово при такій системі remote backup в будь який момент існує мінімум три екземпляри одгного й того ж бекапа.

Ручний – бо фізично керується і потребує втручання оператора. Внаслідок непостійної роботи з носієм уникаються певні технічні проблеми чи імовірність втрати даних внаслідок збою у більш складній автоматичній системі чи навмисного знищення (бо тупо більше ланок і можливостей).

Деякі системи мають георозподілений кластер (клони), що постійно онлайн з резервуванням, балансуванням і власними бекапами...

[smile]

(30-10-2019 17:39)SergM :  

(30-10-2019 16:27)smile :  я так і думав, що "backup retention policy" пройде мимо.

? Ви гадаєте що є лише певне визначення / реалізація "backup retention policy" чи у Вас є якийсь власний контекст (я не зрозумів жарту)?

ти параноідально переживаеш то за цілісність оригіналу, то за збереження цілісності бекапу папочок з домашніми фотками/відео. у промисловому оточенні рішення існує у грамотно виписаних процесах backup strategy по першій болячці і backup retention strategy/policy по другій. які для дому можна і не виписувати , але дуже просто реалізувати за такої мотивації.

Цитата:Почалося з банального питання і взагалі було трохи жартів по принципу "з гармати по горобцях"...

егеж, егеж.

Цитата:

(30-10-2019 16:27)smile :  ручний бекап на "флешку" гарантовано приведе до питання "бля, де бекап?". може ще бути лише уточнююче питання - коли саме настане момент спитати "бля, де бекап?". бо людський фактор - це страшна сила.

Звичайно – хто на відносно малонадійний носій робить бекапи?

"флешка" не дарма в кавичках. основний момент не в надійності "флешки", а в тому, до чого причеплені руки, які роблять ручний бекап. носій рук тут самий ненадійний елемент.

Цитата:

(30-10-2019 16:27)smile :  а просте щотижневе/щоденне носіння стрічки/диску з бекапом з одного офісу в інший - то не "ручний бекап". то такий спосіб remote backup при відсутності технічної чи фінансової можливості його виконувати через канали зв'язку.

Ручний – бо фізично керується і потребує втручання оператора.

так, так, звичайно. скриньку з касетами, яка вилізла у віконце, має взяти у руки оператор швидкого носіння скриньок і швидко-швидко нести у віконце в другому офісі.

https://www.youtube.com/watch?v=kiNWOhl00Ao

[Примат]

у NAS Synology смущает то, что там, как я понял RAID1 какой-то хитрый, вернее сама реализация там правильно названа, но подвох в том, что если накроется сама NAS Synology, то винты из него к компу не подключишь
Если есть специалисты, можете подтвердить или опровергнуть?

[smile]

(31-10-2019 11:17)Примат :  у NAS Synology смущает то, что там, как я понял RAID1 какой-то хитрый, вернее сама реализация там правильно названа, но подвох в том, что если накроется сама NAS Synology, то винты из него к компу не подключишь
Если есть специалисты, можете подтвердить или опровергнуть?

у меня нет опыта работы именно с Synology, но, по аналогии с другими линуксовыми NASами, виндой точно не прочитаешь, линуксом скорее всего можно прочитать, но могут быть варианты.