Не знаю, к чему отнести статью – пусть будет хумор. 😉
Для бэкапов можно использовать не только ЖД, но и ленточные приводы, библиотеку с роботом.
Недавно столкнулся с тем, что фулл-бэкап файл-сервера не выполнился уже второй раз подряд.
В первый раз я погрешил на “грязный” привод библиотеки и запустил очистку.
Сейчас – понял, что дело не в “грязи”.
Анализ кассет, помещенных в сет “File Backup”, показал, что из 20 кассет:
- 10 полные и защищены от перезаписи в ближайшее время;
- 9 имеют ошибку End marker unreadable и не позволяют дозапись;
- и только на одну можно что-то писать. 😉
Я сказал “Ахтунг” и начал чистить “больные” кассеты.
Посмотрим, сможет ли бэкап сам перезаписать “больные” кассеты, когда у них выйдет срок хранения.
А, можно вопрос – зачем пользоваться ленточным накопителем?
Я, понимаю, что это вопрос “веры”, но по-моему NAS это как-то более удобно, да и по деньгам давно сопоставимо.
Просто, я избавился от лент очень давно, так как кошмар их обслуживания был просто невыносим.
1) Скорость. При бэкапе последовательно расположенных данных, скорость записи на ленту гораздо выше скорости записи на ЖД.
2) Емкость/объем. Библиотека HP MSL4048 с одним приводом и роботом занимает в шкафу 4 юнита. При этом, там 48 кассет объемом 400Гб (бывают и больше) и аппаратное сжатие – базы SQL жмутся в 4 раза на лету при скорости архивации ~ 100MB/s. Если приводов будет четыре, можно будет говорить о скорости в 400MB/s (если удасться выдать данные на такой скорости). Файлы жмутся похуже и копируются дольше. В целом, я почти не видел NAS/DAS, такого объема, сопоставимого размера и подобной скорости за аналогичные деньги (а MSL4048 вроде недорого стоит).
3) Offline. Необходимость делать бэкапы на отчуждаемых носителях. Все-таки, винты не предназначены для того, чтобы сделать на них бэкап и достать из NAS.
Ну и самое правдоподобное – у нас тупо нет НАС 😉
Максимум емкости – 2*750 или 8*72. Теоретически, еще есть полка с 14*146, но на практике очень много телодвижений по ее освобождению.
Преимущества лент шикарно расписаны 🙂
Но, последний коммент расставил все по местам.
Кстати, рекомендую http://www.drobo.com
Я, думаю что за 200 000 руб. получить 14 Тб чистого пространства это неплохо, совсем неплохо. Да, к тому же Vmware ready.
Кстати, забыл еще энергопотребление. У полки с дисками оно в разы выше.
Возвращаясь к НАС или не НАС.
Мы планируем покупать НАС и складывать туда наиболее свежие бэкапы. А все, что старее недели-двух – на ленточки.
Ибо у лент страдает скорость поиска.
Ленты хороши для долговременного хранения. Например у нас требование хранить бакапы 1С более двух лет. Никто такой склад на винтах держать не будет.
А вот фиг его знает 😉
Проблема в том, что у меня недостаточно опыта, чтобы говорить про сроки хранения данных на лентах или жестких. Кто-то ленты ругает, кто-то – винты. Учитывая профессионализм обеих сторон, приходится считать, что это – как сексуальные предпочтения 😉
To Alexander E. Vasilev
На всякий случай порекомендую очень неплохую софтину по бэкапу 1С – http://www.effector.com.ua/ (украинские братья молодцы).
У них шикарный и адекватный саппорт.
Стоит недорого и работает like a sharm 🙂
У меня база 40 Гб жмется до 8 Гб.
P.S. Ленты, на мой взгляд, очень недолговечны (мои через 5-7 лет уже не читались толком, пришлось выбросить) и плюс большой риск размагничивания.
Бэкап баз 1С – это же бэкап баз SQL и содержимого сетевых папок “\\file\1CBUH”?
Софтина удобная, согласен. Хотя можно на коленке подобные вещи самому делать (или с помощью средств вроде BackupExec).
По поводу долговечности – мне сложно комментировать – мой стаж в ИТ всего лет 5, из которых админом всего три.
Не совсем так. 1С работает в 2-х режимах файловом или SQL, поэтому какой выбран тот и пользуем для бэкапов, но самый правильный это ее родной и вот эта софтина умеет выгонять пользователей и делать его. Родной содержит не только базу, но и конфигурацию, т.е. метаданные.
На коленке такие решения делать сложно SQL не умеет делать ретеншен. Т.е. нельзя сделать гибкую систему с хранением за каждый день, неделю или месяц. Получается ерунда полная.
Мой 15 лет 😉 Я тут недавно рассказывал студентам про DOS и прерывания IRQ и объяснял почему они должны были быть разными и что раньше IRQ, DMA ставились джамперами на платах, про модемы 14400, BBS и FIDO. Ей-богу, чувствовал себя динозавром 🙂
IRQ – это да 🙂
Помню, втыкал в компы ISA-мультикарты для дополнительных COM’ов и IRQ угадывал. А еще настраивал в DOS звук на SB-compliant картах 😉
Хотя FIDO я уже не застал 🙁
Слушай, а retension – это удаление старых бэкапов по заданному сроку? Если да, то в принципе SQL это умеет. А Symantec BackupExec тем более.
Пока единственный плюс, который я вижу, – выкидывание пользователей. Потому что мне ведь никто не мешает делать бэкапы баз и метаданных (сетевых каталогов) одновременно.
P.S. Помнится, когда я собирал на коленке средство для централизованного бэкапа на основе NTBackup+PowerSHell+WSS3.0, вопрос ротации бэкапов решился просто. Или я неправильно понял значение термина?
P.P.S. Наверное, специализированное средство лучше хранит целостность баз.
SQL маркирует, но не удаляет устаревшие бэкапы и файл бэкапа растет. Мы столкнулись с этим, когда файл вырос до 400 ГБ и нифига не чистился, мы писали в него ежемесячный бэкап. Погуглили и выяснили, что он не умеет этого “из коробки” и стали искать что-то более удобное, чтобы не заниматься изобретением велосипеда и нашли этот софт.
А так как Veritas превратился в полный симантек, то решили, что это более оптимально, тем более, что этот софт любые базы бэкапит и жмет вполне отлично.
Термин означает тоже, что и для лент – перемотку, только в смысле возможности перезаписи устаревших бэкапов.
“Вот за это и не любят” (с) 🙂
“Скорость”, “Емкость”, “Оффлайн”, это все, конечно, важно и нужно, но забыт самый главный аспект системы резервного копирования – “Всегда работает”. А вот с этим у лент, как и познакомился автор, беда.
И если нужного бэкапа в нужный момент – нет, то все “преимущества”, в виде “скорости” или “емкости”, уже ничего не значат.
Да ладно вам. Можно подумать, винты с рейд-массивами не рассыпаются. Или у меня пара лент повалится, или у вас пара терабайтных винтов.
Если не ошибаюсь, у вас же проскакивало исследование винтов от Гугла. Там пять лет едва ли половина переживает.
1. У дисков есть RAID, а у лент – нет. Потеря одного (и даже двух в RAID-6) дисков не означает потери данных. Однако любое механическое повреждение ленты, или механизма в момент чтения означает потерю данных ленты целиком.
2. Данные на дисках можно непрерывно контролировать на целостность на протяжении всей их жизни, и вовремя предотвращать возможные отказы, а о block unreadable на ленте вы узнаете скорее всго только в час “Ч” восстанавливая с нее данные.
> Там пять лет едва ли половина переживает.
Да, но что это меняет? Зато там есть средства predicive failure detection и RAID, что позволяет об этом не задумываться особо. А у лент – нет.
Положа руку на сердце – демагогия. 😉
Кто-то активно использовал ленты на протяжении долгого времени? Причем не старье, а LTO-3, например. У них заявленный срок хранения – 30 лет (причем не на заборе, а на http://h10010.www1.hp.com/wwpc/ru/ru/sm/WF06b/12169-64242-342326-342326-342326-34648-3543409.html).
Да у меня 10 лент помечены, как неперезаписываемые.
Но я вообще не думал не гадал, что такое возможно. Теперь буду знать и отслеживать эту ситуацию 😉
Точно также без мониторинга винтов и рейд-массивов я могу обнаружить, что у меня половина данных бэкап-сервера развалилась.
Кроме того, с точки зрения офлайн-бэкапов, преимуществ у винтов никаких, если только вы не делаете бэкап на массив из кучи дисков, а затем выдергиваете их все.
> У них заявленный срок хранения – 30 лет
“Хранение” не значит “использование”. Я уж не говорю, что эти 30 лет такая же бумажная фикция, как сто тысяч часов MTBF у винтов или 100 лет хранения у CD-R.
Вы путаете резервное копирование и архивое хранение, а это все же разные задачи.
Там же по ссылке – 20000 циклов полной перезаписи/260 фулл бэкапов. Или 1000000 обращений к ленте.
По поводу MBTF – тут (http://www.allbackup.ru/product_info.php?currency=RUR&products_id=375) у LTO2 заявлены 250000 часов.
Поверьте, я представляю себе разницу между архивацией и бэкапом. Вот для тех, кто не представляет – http://blog.aboutnetapp.ru/archives/51 😉
Извините, что с такой иронией отношксь ко всем этим “десяткам тысяч циклов” и “сотням тысяч часов”, дело в том, что я, до сравнительно недавни пор, был в этих вопросах не теоретик, а практик. 🙂
😉
Два апдейта по лентам:
1) Оказывается, привод для лент весьма недешевый. SCSI-редакция для HP MSL4048 стоит 5k$, FC – 10k$;
2) Сейчас привод в MSL4048 (Ultrium920) часть лент LTO3 метит как сбойные. Втыкаю их в отдельно стоящий Ultrium960 – нормально бэкапит. Грешу на драйвера от МС под Ultrium920.
Так как библиотека была гарантийная, создал кейс в техподдержку HP. Провели пару тестов и прислали привод на замену. Так что Happy End.