× Few antiviral products inadequately detect 3proxy as Trojan.Daemonize, Backdoor.Daemonize, etc and many detect 3proxy as a PUA (potentially unwanted program). It may cause browser warning on download page. 3proxy is not trojan or backdoor and contains no functionality except described in documentation. Clear explanation of this fact is given, for example, in Microsoft's article.
Хакер-спец #1 20063APA3A

Организация Backup

I. Intro
II. Tools
III. Strategy

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

Hintы:

 Необходимо выработать несколько документов:

План резервного копирования это самое простое. Но он должен быть исчерпывающим. Для его составления должны привлекаться пользователи, т.к. зачастую только они могут классифицировать свои данные, чтобы определить содержание оперативных и хранимых бэкапов. Обязательным должно быть указание где, как и сколько хранить копии, как осуществлять к ним доступ и какими полномочиями необходимо для этого обладать, как контролировать процесс резервного копирования. Необходимо так же регулярно проверять целостность архивов, проводить контрольное восстановление данных. По плану производится внедрение резервного копирования с использованием доступных средств и затем составляется инструкция оператора.

Пример из реальной жизни. Телекоммуникационная компания. Имеется план резервного копирования, которое регулярно производится. Однажды, в разгар рабочего дня, из-за сбоя SCSI драйвера <запарывается> содержимое дисков на RAID-котроллере основного сервера баз данных, через которую осуществляется биллинг и управление услугами. Единственным выходом остается восстановление из бэкапа. Администраторы пытаются приступить к процессу, но оказывается:  1. Процесс восстановления много-гигабайтной базы занимает длительное время, причем спрогнозировать его они не в состоянии. 2. Клиенты не могут воспользоваться услугами, и, вместо восстановления базы данных, приходится искать временное решение, которое позволило бы использовать хотя бы основные услуги. 3. Весь этот процесс сопровождается постоянными звонками доброжелателей из различных подразделений, указывающих на проблемы с базой. 4. Никто не знает что делать, чтобы реанимировать базу и систему в целом после процесса восстановления и приходится читать документацию. 5. Когда база, наконец, приведена в рабочее состояние, выясняется, что есть накопленная за это время биллинговая информация, но нет никаких средств для ее  обработки и загрузки. 6. После написания на ходу и на коленке, без тестирования, необходимых утилит выясняется, что часть записей оказалась продублирована и их необходимо вычистить. Итог: процесс полного восстановления занял свыше 5 дней. 7. Через еще через 2 дня происходит аналогичный сбой SCSI драйвера.

В чем ошибка? Во-первых в отсутствии резервного сервера, который бы синхронизировался с основным и который можно было бы быстро пустить на замену. Во-вторых в отсутствии правильного плана аварийного восстановления и инструкций. План должен предусматривать не только то, какая информация откуда и куда восстанавливается. План аварийного восстановления должен предусматривать возможность введения <аварийного> режима работы системы на время сбоя - например, без подключения новых услуг но со сбором биллинговой информации. Аварийный режим должен предусматривать и оповещение сотрудников или перевод звонков на службу поддержки пользователей. Возможно, усиление службы поддержки за счет сотрудников других подразделений, чтобы справиться со звонками пользователей. План должен предусмотреть действия, которые необходимо предпринять после аварийного восстановления старых данных. Естественно, все это для разных категорий данных. Процесс восстановления должен быть оттестирован, для этого он должен проводиться регулярно, чтобы учесть возможные изменения системы. По результатам тестирования в плане должны быть указаны все ожидаемые сроки и то, какие операции можно распараллелить. Кроме того, план обязательно должен включать пункт о необходимости анализа причин сбоя и их устранения, причем первичная диагностика должна быть до начала процесса восстановления данных, а по окончании работ должна производиться полная диагностика и устранение причин сбоя, чтобы не допустить повторения проблемы.

По плану аварийного восстановления составляются инструкции администратора. Разумеется, план должен предусматривать и восстановление отдельных файлов по запросу пользователей.

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

IV P.S.

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

Перепечатка данной статьи невозможна без разрешения издательства Gameland