Кращі прайси для обміну файлами в мережі?

Таким чином, у нас є спільний доступ до файлів, який розпочався 10 років тому і розпочався з найкращих намірів. Але зараз він роздувся, там є файли, що ніхто не знає, хто їх туди помістив, важко знайти інформацію, тощо. Ви, мабуть, знаєте проблему. Тож мені цікаво, що люди роблять у цій ситуації. Хтось знає про гідну програму, яка може пройти спільний доступ до файлів і знайти файли, яких жоден орган не торкнувся? Дублікати файлів? Будь-які інші пропозиції щодо очищення цього безладу?

Добре, частка файлів базується на Windows, і це майже понад 3 ТБ. Чи є утиліта там, яка може зробити деяку звітність для мене. Нам подобається ідея, що ми зможемо знайти що-небудь старше 6 місяців, а потім взяти його в архів, лише проблема полягає в тому, щоб поділитись файлами цей великий, що може бути дуже важко зробити вручну.

Ми радимо Клієнтам "випалити землю" і почати свіжий, часто.

Я ще не бачив хорошого рішення, яке не потребує залучення зацікавлених сторін, які не стосуються ІТ. Найкращий сценарій, який я бачив, - це Клієнт, який керував ідентифікацією «управителів» різних областей даних та делегував контроль над групами AD, які контролюють доступ до цих спільних областей тим «управителям». Це спрацювало дуже, дуже добре, але вимагало певної підготовки з боку "стюардів".

Ось те, що я знаю, не працює:

• Іменування окремих користувачів у дозволах. Використовуйте групи. Завжди. Кожного разу. Безвідмовно. Навіть якщо це група одного користувача, використовуйте групу. Робочі місця змінюються, відбувається плинність.
• Дозволяє користувачам, що не входять до ІТ, змінювати дозволи. Ви закінчите "комп'ютерний В'єтнам" (сторони мають "добрі" наміри, ніхто не може вийти, і всі програють).
• Маючи занадто грандіозні уявлення про дозволи. "Ми хочемо, щоб користувачі могли тут писати файли, але не змінювати файли, які вони вже написали" тощо.

Те, що я бачив, працює (деякі добре, інші не дуже):

• Опублікуйте "карту" із зазначенням місця зберігання різних типів даних, як правило, за функціональною областю. Це гарне місце для проведення інтерв'ю з різними відділами та вивчення того, як вони використовують спільні файли.
• Розгляньте "зворотний рахунок" для використання простору або, принаймні, регулярно публікуйте "лідери" користувачів відомчих користувачів простору.
• Чи згадував я іменування груп виключно в дозволах?
• Розробіть план для областей даних, які "ростуть без меж", щоб використовувати старі дані "в режимі офлайн" або на "близьколінійне" сховище. Якщо ви дозволите, щоб дані зростали назавжди, вони зроблять ваші резервні копії з нескінченністю.
• Плануйте якусь тенденцію використання місця та зростання папок. Ви можете скористатися комерційними інструментами (хтось згадав Tree Size Professional або SpaceObServer від JAM Software) або ви можете кодувати щось розумно ефективне, використовуючи програму "du" та якийсь сценарій "клею".
• Файловий сегмент файлів на основі "SLA". Ви можете розглянути як "критично важливу для бізнесу" акцію, яка перетинає відомчі лінії, так і "приємно працювати, але не критично". Ідея полягає в тому, щоб "критично важливі для бізнесу" частки були відокремлені для резервного копіювання / відновлення / обслуговування. Мало думати, щоб відновити 2TB файлів із резервного копіювання, коли все, що було дійсно потрібно для ведення бізнесу, було близько 2 ГБ файлів, трохи нерозумно (і я бачу, що це відбувається).

Я погоджуюся з Еваном, що починати спочатку - це гарна ідея. Протягом багатьох років у моїй компанії я робив 4 "міграції файлів", і кожен раз, коли ми створювали нову структуру і копіювали (деякі) файли, створювали резервні копії старих спільних файлів і переносили їх в офлайн.

Одне, що ми зробили під час останньої міграції, може допомогти вам. У нас була дещо схожа ситуація з тим, що ми назвали нашим "загальним" накопичувачем, де було місце, де кожен міг читати / писати / видаляти. Протягом багатьох років там накопичувалося чимало речей, коли люди поділяли речі по групах. Коли ми перейшли на новий файловий сервер, ми створили новий загальний каталог, але ми нічого не копіювали в нього для користувачів. Ми залишили стару загальну на місці (і назвали її Old Common), зробили її лише для читання і сказали всім, що у них є 30 днів, щоб скопіювати все, що вони захотіли, до нових каталогів. Після цього ми приховали каталог, але ми видалимо його при запиті. Під час цієї міграції ми також працювали з усіма відділами та створювали нові спільні каталоги та допомагали людям визначати дублікати.

Ми використовували Treesize роками, щоб з’ясувати, хто використовує місце на диску. Ми нещодавно пробували Spacehound, і деяким моїм колегам це подобається, але я продовжую повертатися до Treesize.

Після нашої останньої міграції ми спробували створити структуру Архів, яку люди могли б використовувати самостійно, але це не дуже спрацювало. Люди просто не мають часу відслідковувати, що є активним, а що ні. Ми розглядаємо інструменти, які могли б зробити архівування автоматично, і в нашому випадку буде працювати періодично, щоб перемістити всі файли, які не торкалися протягом 6 місяців, на іншу спільну частину.

У 3TB у вас, ймовірно, є багато величезних непотрібних файлів і дублюваних непотрібних файлів. Один із корисних методів, які я знайшов, - це пошук, починаючи з файлів> 100 Мб (я можу навіть у вашому випадку піднятися до 500 МБ), а потім знімати його. Це робить роботу з пошуку реальних космічних відходів більш керованою.

Першим моїм замовленням на підприємстві було б використовувати файловий менеджер / аналізатор / репортер корпоративного файлу / все, що ви хочете, щоб зателефонувати - наприклад, TreeSize Professional або SpaceObServer . Ви можете побачити, які файли є де, сортувати за даними створення, датою доступу та низкою інших критеріїв, включаючи статистику щодо типів файлів та власників. SpaceObServer може сканувати різні файлові системи, включаючи віддалені системи Linux / UNIX, через з'єднання SSH. Це може забезпечити вам велику видимість вашої колекції файлів. Звідти ви можете «розділити і перемогти».

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

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

На нашому файловому сервері Windows 2003 R2 ми використовуємо вбудовану функцію звітування програми File Resource Monitor, вона надсилатиме вам найменш використані списки файлів разом з іншими звітами.

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

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

За найгіршого випадку, ви можете взяти все в автономному режимі і чекати, хто скаржиться. Тоді ви можете дізнатись, хто вони і для чого вони використовували. (Зло, але воно працює.)

Я думаю, що найкраще рішення - перейти на новий привід. Якщо кількість людей, які отримують доступ до акції, є розумною, запитайте їх і дізнайтеся, які частини справді потрібні. Перемістіть їх на нову частку. Тоді закликайте всіх використати нову частку. Через деякий час зніміть стару частку. Подивіться, хто кричить, а потім перенесіть ці дані на нову спільну частину. Якщо ніхто не просить щось протягом 3-6 місяців, ви можете сміливо видалити або архівувати.

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

Таким чином, всі старі речі залишаються доступними, але я можу зняти з резервного розкладу.

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