Опытные мелочи-4, или «Померяемся бэкапами?»

    image Продолжение «опытных мелочей». Предыдущие части: раз, два, три.

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

    Бэкапы — это страховка компании от несчастного случая. Делать бэкапы — это даже не правило, это аксиома. Какой бы ни был прожженный админ, и у него иногда может «дрогнуть рука», и с ошибкой написанный скрипт, или случайно нажатая кнопка способны наворотить много бед, что уж говорить про посыпавшиеся HDD, пожар и прочие катаклизмы. Да, бэкапы затратны (время, ресурсы, оборудование), их сиюминутный эффект неочевиден, но главное что они дают — страховка рисков компании. А это — дорогого стоит. Казалось бы, утверждения понятные всем, но при этом нередко возникает ситуация, когда сервер упал, бэкап есть, а сделать ничего нельзя, система не восстанавливается. И начинаются пляски для бубна с оркестром, вытаскивание хоть каких-то данных и т.п. радости.

    Для начала давайте введем и четко разделим такие понятия как архивирование и бэкап. Например вот так:
    • Архивирование — это резервное копирование с ДОЛГОСРОЧНЫМ хранением данных. Процедура, когда один раз скопировали, и унесли в банковский сейф. Обращение в архив, это скорее исключение чем правило, и процедура это может быть довольно длительной (в зависимости от того где и как хранятся архивы).
    • Бэкап — это резервное копирование с КРАТКОСРОЧНЫМ хранением данных. Процедура, когда копирование происходит регулярно, носители перезаписываются, есть понятие «глубина хранения». При этом доступ к бэкапу обычно должен быть максимально быстрым.

    Архивирование



    Архивирование нужно не всем и не всегда. Чаще всего этот вопрос встает, когда компания выходит за рамки «я, мой друг, жена и курьер», и касается обычно только файлов, финансовых баз, почтовых баз, т.е. тех документов, которые и неэлектронной жизни принято хранить в архивах (письма, приказы, бухгалтерская первичка и т.п.).
    Архивы обычно делаются раз в год и хранятся на внешних носителях где-нибудь в сейфе, в банковской ячейке, на даче у гендиректора (нужное подчеркнуть). Тут все в целом понятно, главное не забывать хотя бы раз в год проверять состояние архива (например одновременно с записыванием нового восстановить часть данных из старого), и следить за носителями, чтобы вы всегда могли прочитать архив любой глубины (например, у меня была ситуация, когда потребовался архив, который был сделан 5 лет назад, и хранился на ленте, стример для которой не только был сломан и списан, но и уже давно не выпускался. Архив конечно прочитали, но сколько нервов и связей для этого потребовалось — лучше не вспоминать).

    Последние пару лет, кстати, все чаще для архивов используем не ленты, а банальные HDD. Их объемов- хватает, скорость работы — достаточна для архива, цена — в рамках разумного, а единый интерфейс подключения (раньше IDE, сейчас SATA) устраняет проблему «сломанного стримера», что немаловажно, т.к. данные можно прочитать практически на любом компьютере, без привлечения спец оборудования (как в случае с лентами). Когда IDE совсем пропадет, вероятно скопируем на SATA (или что там будет после).

    Бэкап


    Задача бэкапа как такового — хранить свежие резервные копии, для быстрого восстановления «случайно\специально удаленного», или «сгоревшего», или «неправильно сконфигурированного». Если архивы обычно хранятся столько сколько живет организация, а иногда и дольше, то для бэкапов уже можно ввести понятие глубина хранения, т.е. время по истечение которого бэкап будет устаревать, и его можно перезаписать более свежими данными. Бэкап в целом можно разделить на две основные части: бэкап данных и бэкап систем, и отдельно стоящий бэкап содержимого систем. Последнее очень обширная и конкретная тема, сильно зависящая от того, содержимое каких именно систем вы хотите бэкапить (почтовый сервер, БД, CRM, настройки ПО и т.п.), здесь ее описывать не будем.

    Бэкап систем

    Бэкап систем — это когда вам нужно бэкапить не отдельные файлы, а целиком всю систему, которая может состоять из нескольких компонентов (например, спец-ПО, база SQL, файловые данные), и восстанавливать ее лучше целиком, нежели по частям. Тут все довольно просто: выбираете устраивающий вас бэкап-софт (цена, функционал, удобство) и бэкапите систему так, чтобы вы гарантированно могли восстановить ее, даже в случае полной поломки сервера. Подходят всевозможные Acronis'ы, Symantec System Recovery и т.д. Важно помнить вот что:
    • вы должны УМЕТЬ восстанавливать из бэкапа. Тренируйтесь где угодно, когда угодно, но вы ДОЛЖНЫ УМЕТЬ это делать.
    • продумывайте что именно вы бэкапите. Это значимо для универсальных серверов, когда, например, на одном сервере крутится БД, ваш внутрикорпоративный сайт и дополнительно прицеплен том под файловые ресурсы. В такой ситуации не стоит ради бэкапа связки «сложнонастроенный SQL + ваш сайт» бэкапить с ним заодно еще и второй файловый том в 1500 Тб. Вообще стремитесь к ситуации «одна задача — один сервер», не вешайте все-все-все на одну машину, а если уж повесили то бэкапьте его «системно».
    • ваш софт должен уметь восстанавливать на другое железо, отличающееся от текущего. И вы должны это хотя бы раз попробовать!
    • «системные» бэкапы, особенно систем постоянно используемых, не стоит хранить глубиной более чем неделя. Подумайте сами, зачем вам бэкап вашего контроллера домена давностью в месяц? В случае критической ситуации вам понадобится САМЫЙ свежий бэкап. А все остальные — это подстраховка, на случай если «самый свежий» по каким то причинам не отработал. Отводить на такую подстраховку больше чем 1-2 итерации, на мой взгляд нелогично и излишне расходует место.
    • есть системы, которые сложно взаимосвязаны со всей инфраструктурой, и восстановить их, даже имея под рукой свежий «системный бэкап» конкретного сервера, бывает нелегко. Навскидку: Active Directory, Exchange и т.д. Выделите время, изучите документацию, и в тестовой среде, хотя бы раз — но попробуйте восстановить АБСОЛЮТНО ВСЕ! Лучше научитесь это делать в спокойной обстановке с Интернетом под рукой, чем с разъяренным начальником над головой.

    Бэкап данных

    Бэкап данных, это бэкап отдельных, самостоятельных данных (в основном это содержимое вашего корпоративного файлохранилища). Здесь много мудрости не нужно — бери да копируй, можно разве что поразмышлять над схемой бэкапа. Я, например, придерживаюсь следующей схемы:

    1. По выходным делается полный бэкап всех данных. Глубина хранения 28 дней, т.е. есть четыре независимых полных бэкапа. Таким образом за последний месяц мы сможем восстановить данные за любой выходной день.
    2. По рабочим дням делается дифференциальный бэкап, с глубиной хранения 14 дней. Таким образом за последние две недели мы можем восстановить данные за любой из дней.
    3. в первые выходные каждого месяца, отдельно от остальных работ, делается месячный бэкап, с глубиной хранения в 12 месяцев. Это нечто среднее между бэкапом и архивом. С одной стороны срок хранения довольно большой, с другой — нередка ситуация когда нужно восстановить данные «пару месяцев назад, максимум полгода». Как вариант, можно не делать месячный бэкап отдельной работой, а просто копировать подходящий недельный.

    Кроме того, я стараюсь придерживаться вот каких правил:
    • использую дифференциальный, а не инкрементальный бэкап. (Если вы не знаете что это такое — обязательно прочитайте документацию, это весьма важные понятия). Мне важнее выигрыш в скорости восстановления, нежели в объеме резервных копий.
    • планирую время бэкапа так чтобы успевать до утра. Если бэкап выполняется дольше — разбиваю его на несколько работ, несколько серверов, или поднимаю вопрос про другое, более скоростное, оборудование.
    • в расписании бэкапа стараюсь придерживаться промежутков связанных с неделями(7 дней, 28 дней и т.д.) и не привязываться к «первым\последним дням месяца». Неделя — довольно постоянная величина, 7 дней и в большинстве случаев суббота, воскресенье — это выходные.
    • использую диски, а не ленты. Мне не нравится дорогостоящий посредник-стример между данными в бэкапе и данными в файлохранилище. Если он по каким то причинам не работает, то надолго нарушается вся система бэкапа. Если использовать жесткие диски, то этого можно избежать.
    • стараюсь чтобы логически самостоятельная часть данных лежала в отдельном бэкапе. Например, если говорить про Symantec Backup Exec, то одна работа=одна media. Очень не люблю ситуацию, когда одна работа «размазана» по нескольким файлам. Это не только вносит сумбур в систему, но и в случае случайного затирани одного из файлов («рука дрогнула») наносит вред не только одной работе но и всем соседним.
    • в обязательном порядке использую софт с уведомлениями по почте. Если это самописный скрипт — никто не мешает дописать кусочек, который будет проверять хотя бы наличие нового бэкапа, его размера и слать данные по почте. Это сильно экономит время в мониторинге бэкапа.

    Кроме всего прочего модно также использовать т.н. «моментальные» бэкапы, небольшой глубины (1-2 дня) а-ля служба VSS в Windows, когда пользователи сами могу выбирать что восстановить из последних версий документа. Это очень помогает, когда пользователь утром отредактировал документ, а в обед его удалил и прсит восстановить утренний вариант.
    Также можно использовать DFS систему в роли постоянного онлайн бэкапа, но это стоит описать в отдельном посте, что я позже и сделаю.

    Продолжение следует.

    P.S. Напомню, я не устанавливаю правил, а делюсь своим опытом, опытом НЕуниверсальным, полученным в небольших организациях (30-500 ПК). Если у вас принято делать иначе — с удовольствие прочитаю об этом в комментариях.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 47

      +3
      Не увидел в тексте абзаца с описанием как и чем делаются бекапы у автора, а жаль. Тема мне достаточно интересна, так как текущее средство (кобиан бекап) меня не совсем устаревает, в нём не хватает инструментов для сбора всех полных копий, разбиение на размер двд и складирование в одном месте для записи на двд раз в квартал. Подумываю написать самому скрипт, но увы он будет огромный.
        +1
        ну видимо так тому и быть, сам писал скрипт, по крону запускается, 7зипом архивируется…
          +2
          Специально не стал указывать чем делаю, т.к. не важно чем — важно как, важны принципы, а софт можно выбирать почти любой, у большинства есть нужный функционал.
          если говорить конкртено, то делал (и делаю) самописными скриптами (использовал 7zip и winrar), Symantec Backup Exec (одна из любимых программ) и Symantec System Recovery (после того как она обновилась до 9 версии как софт для системного бэкапа она мне нравится все больше и больше)
          но, повторюсь, есть масса других не менее хороших програм, тот же Acronis, DPM, Handy Backup, Comodo и т.д. и т.п.
            0
            Было бы интересно посмотреть как раз скрипты, платный софт не всегда даже удобней их.
              0
              например такой момент — запуск скрипта на стороне клиента или сервера? как лучше.
                0
                Имхо, проще так: бэкап клиентского ПК инициируется со стороны клиента, если по какой-то причине бэкап не запустился по расписанию, можно выставить «галочку» на выполнение задания при следующем старте ПК.
                По возможности складировать создаваемую копию локально и затем переносить в хранилище.
                  0
                  зависит от того что вы бэкапите.

                  Если это файловые данные — то правильнее стремится к тому, чтобы все важные файлы лежали в сети (соответственно бэкап работает на стороне сервера).

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

                  А если все таки надо (клиент банки, спец-по и т.д.), и бэкапите не специализированным ПО (типа Symantec с его агентами, или тем же DLO) а скриптом, то запускайте на стороне клиента. Так вы убираете лишнее звено (из цепочки «ЗапускСкриптаНаСервере-ОбращениеНаРабСтанцию-КладемБэкапНаСервер» убираются не нужные первых два шага).

                  И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало.
                    0
                    «И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало»

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

                    а как вы управляете расписанием резервного копирования?
                    например, есть 3 файловых сервера, есть 1 сервер под бэкапы. если изначально настроить расписание из предположения что каждый ФС будет обрабатываться 2 часа, и поставить в расписание их с интервалом в 2,5-3 — в какой-то момент бэкапы могут «наложиться». что либо просто приведет их длительному выполнению, либо к сбою в итоге.
                    а если бэкап-серверов и источников много — уже явно не получится обойтись простым расписанием «назначенных задач». т.к. нужен и полный список заданий и штатное время выполнения и объем и прочая.
                  +1
                  Из бесплатного под Windows — Cobian Backup. Гибкий и надёжный (нужно только имеющуюся в комплекте библиотеку 7za.dll заменить на свежую).
                    0
                    Ага, четырьмя постами выше от того же автора:

                    … так как текущее средство (кобиан бекап) меня не совсем устаревает…
                    0
                    я в одной из следующих статей расскажу про самописный скрипт для бэкапа. Специально писал что был довольно универсальный, с параметрами и т.п.
                    0
                    А такую систему как Bacula, кто-нибудь использует? Есть положительные впечатления? Лично у меня она неплохо работает, но после Symantec'а как-то не так все, а на этом месте работы не хотят покупать symantec.
                      0
                      Использую, совместно с автоматизированной настройкой клиентов через Puppet.
                        0
                        Да, я тоже, может быть вы заодно и zabbix как сервис мониторинга используете?
                          0
                          Нет, пока :)
                        0
                        Используем. Впечатления — только положительные.
                          0
                          а web-интерфейс вы какой используете? или только консоль?
                            0
                            Консоль. Да и та нужна раз в месяц, когда что-нибудь затыкается и надо посмотреть status dir, или когда что-то восстанавливаем.
                              0
                              Только BAT. Сейчас подумал: «Может web-bacula стоит поднять для контроля состояния...» Для управления ИМХО не нужно.
                                0
                                А для управления webacula и не годится, там конечно есть прямой доступ в консоль, но ИМХО он не удобен. Зато посмотреть статистику и общие отчеты можно. Хотя у меня все это льется на почту, поэтому заходить туда возникает необходимость исключительно редко. Хотя и сервис-то не тяжелый так, что это скорее приятное не отягощающее дополнение.
                                  0
                                  Что есть разные веб-интерфейсы, это я знаю. Когда я настраивал Bacula, pweb у меня завёлся криво. С той поры для управления использую только BAT (Bacula Administration Tool).
                            0
                            Использую.
                            Хорошая, годная система.
                          +1
                          Мне для бэкапа фалов на винде понравился SyncBack Pro (хотя и бесплатная версия вполне функциональна). На FreeBSD самописные скрипты.
                            0
                            а можете про скрипты по подробней?
                              0
                              Здесь я описывал и там же в комментариях хороший человек подсказал скрипт для бэкапа в дропбокс. Так что примерно тоже самое, только с этим новым скриптом бэкапится в дропбокс.
                                0
                                ну и на tar ещё перешёл)
                                  +1
                                  спасибо, попробую у себя сделать такое

                                  да, лучше на tar сразу. rar как то смущает
                                    0
                                    Кстати, чтобы tar делал дифференциальные бэкапы, есть у кого-нибудь готовое решение? Не хочется что-то изобретать велосипед, сейчас у меня инкрементальные используются через скриптинг.
                                    Под FreeBSD, если что.
                        +1
                        У нас там система архивов была проста. файловый архив за последние 3 дня хранится в незапакованном виде. затем более поздние файлы ежедневно архивируются. Ну и ежемесячно делается архив этих файлов. А бэкапы делались отдельно системы и отдельно каждой программы. в случае чего поднимается хоть «голая» система и на неё восстанавливаются программы. А в шкафах было еще проще. настроил систему — работает. отзеркалил винт рэйдом. вставил второй сделал копию — вот тебе и бэкап.
                          +2
                          Спасибо, очень, очень дельный текст. Практически выхватили у меня из рук одну из тем статей на Хабре, ну, впрочем, тема такая важная, что я не в обиде.

                          Отдельное спасибо за привлечение внимания к таким вещам, как разница между «архивом» и «бэкапом», сомнительной ценности лент для бэкапа, и важности процесса восстановления и тестирования бэкапов после создания и архивов во время хранения.
                          Я обратил внимание, что об этом мало задумываются. А зря.
                            0
                            А вы напишите тоже. Разверните свой взгляд. Думаю это будет полезно многим.
                            0
                            В разделе хранения носителей (особенно — лент) в банковских ячейках, необходимо отметить, что климатические условия ячеек (температура и влажность) не всегда могут соответствовать условиям хранения носителей, и архив может выйти из строя быстрее, чем «раз в год».
                              0
                              Ну что же, все верно. Сам использую Symantec Backup Exec, особенно когда с ней разберешся.
                                +2
                                «есть системы, которые сложно взаимосвязаны со всей инфраструктурой, и восстановить их, даже имея под рукой свежий «системный бэкап» конкретного сервера, бывает нелегко. Навскидку: Active Directory, Exchange и т.д.»

                                а можно этот момент осветить чуть подробнее: с какими проблемами восстановления приходилось сталкиваться?
                                может быть даже в виде отдельной статьи, ведь скорее всего систем и «заморочек» было много?

                                используется ли в вашей инфраструктуре несколько exchange серверов и приходилось ли восстанавливать первый/рядовой экс? были ли проблемы связанные с AD (сайтами) или с чем-то еще?

                                делались ли оптимизации для поднятия SQL-серверов? (когда базы по дцать гигов и их кучка, поднятие всего требует времени. а «работать уже хотят все и сразу») опять же, когда баз много и они большие, возникает вопрос схемы резервного копирования — в случае SQL речь уже идет не только о самой БД, но и о логах. которые тоже любят расти/обрезаться.

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

                                действительно ли оказалось выгоднее иметь несколько ежедневных диффов вместо shadow copy на файловых хранилищах? может быть в процессе эксплуатации выявлены какие-то проблемы, мешающие полноценному использованию теневых копий?

                                можно ли по заголовку поста «про бэкапы» считать, что здесь рассмотрен именно аспект сохранения данных, а не обеспечения непрерывности работы? хотелось бы почитать как сделана именно непрерывность :) особенно, если полноценно перешли на экс 2007 (про SQL к сожалению поста еще не было, но если есть и SQL 2005+ — тоже интересно, используется ли зеркалирование/standbay и тп. в первую очередь, правда, с точки зрения непрерывности.)

                                ну и уже отвлеченный вопрос: поднятие упавшего сервиса выполняется руками или автоматизированно какой-то системой? например, если упал SQL, на который завязан sharepoint. или FS + DC и тп.

                                как реализовано восстановление системных объектов? т.е. если удаляем учетку в DC, поднимается ли она из какого-то бэкапа спецсофтом или ручками вынимается из захоронения и настраивается в первоначальный вид руками. вопрос больше по связанным сервисам, т.к. одного только SID не всегда достаточно (взять тот же экс)
                                  +1
                                  Вы наверное хотите, чтобы я следующие полгода отшельником провел за клавиатурой, рассказывая все то, что вы спрашиваете :)
                                  Нет, правда, ваши вопросы замечательные, но это же настолько обширная тема, что можно писать и писать, заваливая простынями, а хочется пройтись по каким то вехам, что-ли, ну или хотя бы чтобы было интересно читать, а я, честно говоря, сомневаюсь, что очень многим понравится статья про нестандартное восстановление Exchange, где не столько интересны идеи и принципы, сколько просто довольно примитивный поиск решения по разным источникам, и с тем или иным успехом применение его.

                                  Не забывайте также, что мой опыт ограничен условиями применения, с компаниями больше чем 500 ПК я не работал, а это накладывает отпечаток на решения. Скажем, автоматическое восстановление сервиса — это скорее исключение в моей ситуации, чем правило (я имею в виду автоматическое восстановление SQL, или там SCR в Exchange и т.п.)

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

                                  0
                                  о разделении понятий бэкап и архивирование добавлю, под архивированием часто подразумевается удаление скопированных данных.
                                    0
                                    Юзаю систему Bacula(конечно костыльная сама по себе и многое бы по другому, но зато умеет бэкапить и с никсов различных и с винды), схема бэкапа такая:
                                    Раз в месяц full backup, далее каждый рабочий день incremental backup, и каждое воскресение differencial backup.
                                    У incremental время жизни 7 дней, больше не имеет смысла, получается в конце месяца имеем 1 фул, 4 дифа и несколько инкрементальных(не более 5) за последнюю неделю.
                                      0
                                      Прокомментируйте пожалуйста, как вы рассчитали риски «смерти» одного из жестких дисков на которых хранятся месячные бекапы, ведь в таком случае теряется огромное количество информации.
                                        +1
                                        Я исходил из следующих соображений:
                                        — «месячные» диски это отдельные диски, они используются редко, раз в месяц, и по умолчанию «сыпаться» не должны
                                        — исходя из наших объемов, на один 2 ТБ диск влезает 2 месячных бэкапа с некоторым запасом на будущее, соответственно если он сгорит — то мы потеряем максимум наш архив-бэкап за два месяца, причем не по порядку. т.к. на каждом конкретном диске только два месячных архива, и мы их чередуем (январь-март, февраль-апрель и т.д.). Ситуация выглядит не такой уж страшной.
                                        — кроме того возможны варианты, например: например незаслуженно забытое копирование на ВНЕШНИЕ «месячные» диски (их можно насовать хоть гроздью из 12 штук, по одному на каждый месяц) или копирование на диск и складирование в сейф руководителя (некий такой не совсем архив, но и уже не бэкап, дешевая альтернатива хранению ВНЕ офиса). Последний вариант (копирование на внешний диск, например через крэдл, и отключение его от сервера на год) вообще на мой взгляд весьма приемлем, если закрыть глаза на необходимость ручных действий.
                                        — и последнее: обращение к месячным бэкапам на моей практике скорее исключение чем правило, и когда просят восстановить что-то старее, чем несколько месяцев, то обычно точных дат не просят, люди вполне готовы удовлетвориться не «мартом» а «январем».
                                          0
                                          А у меня бэкапы хранятся на выделенном хранилище с 6ым рейдом, конечно если пожар будет, то лягут все бэкапы разом, но эти не столь важные бэкапы, а 6ой рейд спасает от вылета 2х хардов, чего имхо пока вполне достаточно.
                                            0
                                            дело не в надежности самого хранилища, а в объемах и сроках хранения.
                                        0
                                        Что-то как-то с ног на голову: делать бекапы потому что все делают.
                                        Начинать надо с противоположного: с плана восстановления — сразу будет видно и необходимую глубину и т.п.
                                          +1
                                          Вы очень правильно заметили, что надо разделять бекап и архивирование. Многие используют бекап как архив, что не есть гуд.

                                          Но Вы неверно разделяете эти понятия. Краткосрочность/долгосрочность хранения данных можно установить и в бекапе и в архиве, но у этих систем принципиально разные функции.

                                          У нас в компании есть такая поговорка "Backup for recovery, archiving for discovery", что значит «Бекап для восстановления, архивирование для поиска». В идеале должны существовать обе эти системы, они должны быть интегрированы между собой и обладать сквозной дедупликацией.
                                            0
                                            Интересно: когда я писал дипломный проект, я от одного человека услышал мнение, что мол архивы не нужны, объёмы жёстких дисков можно считать бесконечными…
                                              0
                                              к сожалению, объемы ИТ-бюджетов для покупки этих дисков не бесконечны
                                                0
                                                Вот и я о том же. Более того, когда всё это дело начнёт у них тормозить (а они проходили уже через это), они будут винить плохого программиста.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое