Скрипт автоматичної архівації даних

[Sandr]

Доброї ночі всім!

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

Отже, скрипт повинен виконувати наступні операції:
-- виділяти всі теки й файли в поточній теці;
-- потім запаковувати все це в формат tar.gz;
-- автоматично формувати назву архіву відповідно до дати створення (2008.08.01.tar.gz);
-- потім створювати з'єднання з віддаленим ftp-сервером за відомим логіном і паролем (user/pass);
-- і нарешті записувати новостворений архів у теку backup на віддаленому ftp-сервері.

За будь-які поради щодо цього скрипта буду вдячний  

P.S. Якщо моя фантазія виходить за рамки можливостей системи, то вибачаюся  

[Михайло Даниленко]

name="$(date +%Y.%m.%d).tar.gz"
tar -czvf $name *
true | lftp -e "put $name -o /remote/backup/dir/$name" remote.host
# user and pass are specified in ~/.netrc or in cmdline with flag -u user,pass

[BM]

Доброї ночі всім!

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

Отже, скрипт повинен виконувати наступні операції:
-- виділяти всі теки й файли в поточній теці;
-- потім запаковувати все це в формат tar.gz;
-- автоматично формувати назву архіву відповідно до дати створення (2008.08.01.tar.gz);
-- потім створювати з'єднання з віддаленим ftp-сервером за відомим логіном і паролем (user/pass);
-- і нарешті записувати новостворений архів у теку backup на віддаленому ftp-сервері.

Ідея дуже погана, IMO, а скрипт й ще гірший.

Якщо є повний бекап /here/your/path, то треба просто створити нову директорію рядом, назвавши її по now(), створити жорсткі лінки на кожен файл, а потім поверх чере RSync або Unison синхронізувати. Вийде так, що кожен новий снапшот буде тримати тільки дельту зміни на рівні файлових одиниць. А при страшенному бажанні, просто в tar.gz можна закрутити останню директорію й вийде остання версія архіву.

Якщо на бекап сервері ZFS (Solaris — це те що зазвичай ставлять на серверах), то навіть і цього хардлінкування не треба: просто створити черговий ZFS снапшот (по часу це займає пару кліпань очима), який буде тримати дельта різницю на рівні блоків, що дасть економити диск найбільш ефективно й RSync'анутись.


HTH...

[Praporshic]

Solaris — це те що зазвичай ставлять на серверах

Оце вже не треба . Воно далеко не так.
Welcome to real world! (С)

[BM]

Оце вже не треба . Воно далеко не так.

Ну це ще залежить де. Там де все це критично, то крутити бекапи на ext3 — це те саме що сидіти на пороховій бочці й закурювати. XFS ще гірше, але це вже кому як...

Доречі, у мене була така неприємна фігня. Як злісний ненависник ext3 я завше її критикував і рекомендував її обходити десятою дорогою. Але-ж нє, ото-ж бо одміни знають краще. Збудували партицію на 3+ TB й запхали утуди бекап. А потім, коли воно дуже твердо впало (з кернел паніком), то fsck... помирав від "Unable to allocate memory". Виявилось, воно так дибільно задизайнене, що хапає весь індекс нод в память. Звісно, на 32 бітах сподіватись таку кількість памяті за'alloc'ити може тільки повний ідіот. А скільки ще такого «геніального дизайну» в Linux? Досить тільки порівняти обробку й роботу процесів з ядром, й одразу зрозумієш чому треба ставити Solaris, хоч він потребує більше старань писати драйвери й трохи повільніший.

P.S. Ну, я продовжую обходити ext3 й далі...

[Praporshic]

Ну це ще залежить де. Там де все це критично, то крутити бекапи на ext3 — це те саме що сидіти на пороховій бочці й закурювати. XFS ще гірше, але це вже кому як...

Мені якось все одно яка ФС - резервні копії створюються "силами"  SAN storage  

[Sandr]

Ідея дуже погана, IMO, а скрипт й ще гірший.

Якщо є повний бекап /here/your/path, то треба просто створити нову директорію рядом, назвавши її по now(), створити жорсткі лінки на кожен файл, а потім поверх чере RSync або Unison синхронізувати. Вийде так, що кожен новий снапшот буде тримати тільки дельту зміни на рівні файлових одиниць. А при страшенному бажанні, просто в tar.gz можна закрутити останню директорію й вийде остання версія архіву.

Якщо на бекап сервері ZFS (Solaris — це те що зазвичай ставлять на серверах), то навіть і цього хардлінкування не треба: просто створити черговий ZFS снапшот (по часу це займає пару кліпань очима), який буде тримати дельта різницю на рівні блоків, що дасть економити диск найбільш ефективно й RSync'анутись.

Той скрипт взагалі-то робочий... А от Вашої ідеї я щось взагалі не збагнув  :-/

[BM]

Мені якось все одно яка ФС - резервні копії створюються "силами"  SAN storage  

Згоден. Теоретично. От тільки практично SAN ще треба вміти підтримувати. :-) Й це трапляється дуже рідко на й без того рідкісний коефіцієнт отих подеплояних SAN. Добав ще його звєрську ціну й посади зверху йолопа-мавпу-оператора — отримаєш повну картину «переваг».

[BM]

Той скрипт взагалі-то робочий... А от Вашої ідеї я щось взагалі не збагнув  :-/

1. http://www.mikerubel.org/computers/rsync_snapshots/
2. http://www.backupcentral.com/components/com_mambowiki/index.php/Rsync_snapshots

HTH.

[raven]

Ще можна використати якийсь контроль версій. darcs, наприклад.

[BM]

Ще можна використати якийсь контроль версій. darcs, наприклад.

Можна, але обережно, бо:
1. лінки/хардлінки
2. скриті файли й директорії
3. великі бінари
4. де-коли може покорячити текстові файли, думаючи що це сорс. І деякі документи будуть пошкоджені, наприкклад ті, що використовують XML.

[Praporshic]

От тільки практично SAN ще треба вміти підтримувати. :-) Й це трапляється дуже рідко на й без того рідкісний коефіцієнт отих подеплояних SAN. Добав ще його звєрську ціну й посади зверху йолопа-мавпу-оператора — отримаєш повну картину «переваг».

А от це - вже не моя відповідальність і не мої проблеми