<?xml version="1.0" encoding="UTF-8" standalone="no"?><rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" version="2.0">

<channel>
	<title>Обитель UNIX</title>
	<atom:link href="http://blog.unixstyle.ru/feed/" rel="self" type="application/rss+xml"/>
	<link>http://blog.unixstyle.ru</link>
	<description></description>
	<lastBuildDate>Fri, 13 Oct 2017 10:52:42 +0000</lastBuildDate>
	<language>ru-RU</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.8.23</generator>
	<item>
		<title>Восстановление данных с RAID5</title>
		<link>http://blog.unixstyle.ru/357/vosstanovlenie-dannyih-s-raid5/</link>
		<comments>http://blog.unixstyle.ru/357/vosstanovlenie-dannyih-s-raid5/#respond</comments>
		<pubDate>Fri, 13 Oct 2017 10:52:42 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=357</guid>
		<description><![CDATA[<p>Если так случилось, что 2-а из N дисков md RAID5 вышли из строя, но при этом они имеют какие-то признаки жизни, на помощь могут придти следующие наборы команд (если вы не знаете, что они делают не выполняйте их!): mdadm --stop /dev/mdX mdadm --assemble --force /dev/mdX /dev/sdX /dev/sdY /dev/sdZ ... и sysctl dev.raid.speed_limit_max=0 sysctl dev.raid.speed_limit_min=0 После [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/357/vosstanovlenie-dannyih-s-raid5/">Восстановление данных с RAID5</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/357/vosstanovlenie-dannyih-s-raid5/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>Восстановление данных с NTFS</title>
		<link>http://blog.unixstyle.ru/340/vosstanovlenie-dannyih-s-ntfs/</link>
		<comments>http://blog.unixstyle.ru/340/vosstanovlenie-dannyih-s-ntfs/#respond</comments>
		<pubDate>Wed, 18 Feb 2015 05:55:26 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=340</guid>
		<description><![CDATA[<p>У хорошего знакомого посыпался жесткий диск, в &#171;мастерской&#187; сказали, что всё безнадежно. При подключении жесткого диска BIOS отказывался у них его определять. Предложил ему свои услуги на безвозмездной основе и без каких-либо гарантий к восстановлению данных. Первые три шага стандартные: 1. подключение накопителя через кабель USB-2-SATA. 2. заглянуть в SMART и лишний раз убедиться, что [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/340/vosstanovlenie-dannyih-s-ntfs/">Восстановление данных с NTFS</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/340/vosstanovlenie-dannyih-s-ntfs/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>uwsgi separate stdout/stderr logging via logfile</title>
		<link>http://blog.unixstyle.ru/334/uwsgi-separate-stdoutstderr-logging-via-logfile/</link>
		<comments>http://blog.unixstyle.ru/334/uwsgi-separate-stdoutstderr-logging-via-logfile/#comments</comments>
		<pubDate>Thu, 15 May 2014 13:16:20 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=334</guid>
		<description><![CDATA[<p>Согласно документации в uwsgi есть встроенная возможность логирования запросов и ошибок в отдельные файлы. Для этого достаточного прописать req-logger = file:/path/to/log/access.log logger = file:/path/to/log/error.log Однако при указаннии привиденных директив уверенно возникала ошибка: Thu May 15 16:56:57 2014 - unable to find logger file при подключении syslog логирования ошибка менялась на: Thu May 15 16:58:21 2014 - [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/334/uwsgi-separate-stdoutstderr-logging-via-logfile/">uwsgi separate stdout/stderr logging via logfile</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/334/uwsgi-separate-stdoutstderr-logging-via-logfile/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>icloud.com и spamhause.com</title>
		<link>http://blog.unixstyle.ru/327/icloud-com-spamhause-com/</link>
		<comments>http://blog.unixstyle.ru/327/icloud-com-spamhause-com/#comments</comments>
		<pubDate>Wed, 12 Feb 2014 16:15:08 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=327</guid>
		<description><![CDATA[<p>Это позор, товарищи! icloud.com (сервис Apple) использует RBL/XBL в данном случае spamhause.com в качестве своих SMTP фильтров. В рассматриваемом примере они отказались принимать письмо от gmail.com. По всей видимости, школота проникает и в крупные корпорации.</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/327/icloud-com-spamhause-com/">icloud.com и spamhause.com</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/327/icloud-com-spamhause-com/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>Для чего нужен virbr0-nic</title>
		<link>http://blog.unixstyle.ru/320/dlya-chego-nuzhen-virbr0-nic/</link>
		<comments>http://blog.unixstyle.ru/320/dlya-chego-nuzhen-virbr0-nic/#respond</comments>
		<pubDate>Thu, 06 Feb 2014 09:31:45 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=320</guid>
		<description><![CDATA[<p>При использовании KVM в списке интерфейсов основной системы появляется минимум два дополнительных интерфейса virbr0 и virbr0-nic. Назначение первого говорит само за себя &#8212; виртуальный мост, который будет связывать созданные Вами виртуальные машины с основной машиной. Назначение второго является не очевидным и в первые минуты загадочным. Если выполнить команду: # brctl show bridge name bridge id [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/320/dlya-chego-nuzhen-virbr0-nic/">Для чего нужен virbr0-nic</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/320/dlya-chego-nuzhen-virbr0-nic/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>Мегабайт: история ошибки</title>
		<link>http://blog.unixstyle.ru/275/megabayt-istoriya-oshibki/</link>
		<comments>http://blog.unixstyle.ru/275/megabayt-istoriya-oshibki/#respond</comments>
		<pubDate>Sun, 26 Jan 2014 21:09:49 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=275</guid>
		<description><![CDATA[<p>Физики или математики не раз задавались вопросом: &#171;почему Мегабайт равняется не 1 000 000 байт, как это следует из его названия?&#187;. Своими корнями приставка Мега уходит в систему Си, в которой величина Мега равна 106. Однако в компьютерном мире Мегабайтом величают величину равную 1 048 576 байтам. Забегая вперед скажем, что это грубейшая ошибка. Правильным [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/275/megabayt-istoriya-oshibki/">Мегабайт: история ошибки</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/275/megabayt-istoriya-oshibki/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>preseed и GPT</title>
		<link>http://blog.unixstyle.ru/268/preseed-gpt/</link>
		<comments>http://blog.unixstyle.ru/268/preseed-gpt/#respond</comments>
		<pubDate>Sun, 26 Jan 2014 18:59:38 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=268</guid>
		<description><![CDATA[<p>Не секрет, что MSDOS разметка жесткого диска уходит в небытие. Размеры дисков с каждым годом растут, а она ограничена размерами не более 2TB. Продолжительное время эксплуатируемые системы поставлялись с дисками до 2TB для системных разделов, расположенных на программном MD RAID массиве. Речь идет именно о системным разделах, для которых такие размеры более чем достаточные, так [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/268/preseed-gpt/">preseed и GPT</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/268/preseed-gpt/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>debugfs практическое руководство</title>
		<link>http://blog.unixstyle.ru/218/debugfs-prakticheskoe-rukovodstvo/</link>
		<comments>http://blog.unixstyle.ru/218/debugfs-prakticheskoe-rukovodstvo/#respond</comments>
		<pubDate>Thu, 23 Jan 2014 11:25:45 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=218</guid>
		<description><![CDATA[<p>При восстановлении системы после сбоев жесткого диска (например, при восстановлении программного RAID1 массива в случае выхода из строя двух жестких дисков) крайней полезной бывает информация об использовании файловой системой дефективного сектора. Существует ряд незаменимых руководств: Bad block HOWTO for smartmontools Find File that Owns a Given Block Большинство указанных руководств предлагают использовать команду fdisk -lu [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/218/debugfs-prakticheskoe-rukovodstvo/">debugfs практическое руководство</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/218/debugfs-prakticheskoe-rukovodstvo/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>Удаление большого файла с EXT3 раздела без остановки системы</title>
		<link>http://blog.unixstyle.ru/200/udalenie-bolshogo-fayla-s-ext3-razdela-bez-ostanovki-sistemyi/</link>
		<comments>http://blog.unixstyle.ru/200/udalenie-bolshogo-fayla-s-ext3-razdela-bez-ostanovki-sistemyi/#respond</comments>
		<pubDate>Wed, 22 Jan 2014 10:18:29 +0000</pubDate>
		
				<category><![CDATA[UNIX®]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=200</guid>
		<description><![CDATA[<p>Удаление большого файла или файлов на EXT3 разделе может превратиться в сущий ад на работающей системе. Проблема заключается в том, что при удалении даже не используемых больших файлов, файловый раздел с EXT3 сильно деградирует по производительности и другие дисковые операции серьезно проседают (если не сказать большего &#8212; они просто останавливаются). Детально проблема описана в документе [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/200/udalenie-bolshogo-fayla-s-ext3-razdela-bez-ostanovki-sistemyi/">Удаление большого файла с EXT3 раздела без остановки системы</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/200/udalenie-bolshogo-fayla-s-ext3-razdela-bez-ostanovki-sistemyi/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
		<item>
		<title>Резервное копирование MongoDB</title>
		<link>http://blog.unixstyle.ru/183/rezervnoe-kopirovanie-mongodb/</link>
		<comments>http://blog.unixstyle.ru/183/rezervnoe-kopirovanie-mongodb/#comments</comments>
		<pubDate>Sat, 18 Jan 2014 19:48:57 +0000</pubDate>
		
				<category><![CDATA[NoSQL]]></category>

		<guid isPermaLink="false">http://blog.unixstyle.ru/?p=183</guid>
		<description><![CDATA[<p>В далекие времена довелось поработать с такими комбайнами как система резервного копирования Bacula и Amanda. Однако в системах построенных изначально на высокой доступности (HighAvailability) их применение не совсем оправдано. Причина &#8212; большая часть конфигурации хранится в GIT/SVN, каждый узел системы настраивается через puppet, chef или cfengine. Таким образом в случае выхода из строя одного сервера [&#8230;]</p>
<p>The post <a rel="nofollow" href="http://blog.unixstyle.ru/183/rezervnoe-kopirovanie-mongodb/">Резервное копирование MongoDB</a> appeared first on <a rel="nofollow" href="http://blog.unixstyle.ru">Обитель UNIX</a>.</p>
]]></description>
		<wfw:commentRss>http://blog.unixstyle.ru/183/rezervnoe-kopirovanie-mongodb/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		<dc:creator>Artyom Nosov</dc:creator></item>
	</channel>
</rss>