Перенесення профілю thunderbird на інший диск

Сьогодні, розгрібаючи свої поточні завдання, наткнувся на наступну: перенести профіль поштового клієнта Thunderbird на диск з Raid1, налаштувати бекап для профілю. Ну, що ж поїхали ..

Почнемо з питання, який повинен задавати собі кожен перед тим, як почати щось робити: навіщо це взагалі потрібно? У моєму випадку, система, як і папки користувачів, тобто / Home / * по-замовчуванню знаходяться на системному SSD диску. Причина цього історична, в момент переходу на Linux, інші диски були в рейді від Windows, що вимагало додаткової роботи з ними по перенесенню даних і створення рейду в Linux. Загалом, було вирішено, перенести профіль (а соответсвенно і всі дані) поштового клієнта з SSD диска на дзеркальний. По-перше, це хоч трохи, але розвантажить системний диск, по-друге дзеркало, збереже дані в разі вильоту дисків. Наступний важливий момент, знову каcается збереження даних - це бекап. Виходячи зі свого досвіду, вважаю, що бекап повинен бути завжди все. Ще краще, якщо у вас буде навіть бекап, бекапов. Нехай краще він ніколи не стане в нагоді, але буде.

Тепер, коли ясно, що і навіщо я захотів зробити, давайте розбиратися, як це зробити. Почнемо з перенесення профілю:


Тут ми змінили, параметри isRelative і Path
  • Ось і все, профіль перенесений, запускаємо Thunderbird, все повинно працювати
  • Оскільки я трошки програміст, я не став витрачати час на пошук готових рішень, вирішив все написати швиденько сам.

    Для написання, нашої чудо-бекап системи, використовуємо звичайний bash скрипт.

    Почнемо розбиратися з кінця:

    1. Стежити за кол-вом бекапов будемо наступним чином: сортуємо все архіви по мітці часу, і видаляємо старіші
    2. Запускати скрипт, буде кожні 4 години, при цьому в разі наявності архіву за потрібну дату (наприклад, в проміжку від минулого СБ до сьогодні), будемо завершувати скрипт.
    3. Найскладніше - запит на зупинку thunderbird. План наступний, встановлюємо zenity (який у мене вже стояв за замовчуванням), в разі запущеного thunderbird просимо закрити його, щоб зробити бекап. Якщо дозволяють, робимо бекап, якщо немає, завершуємо скрипт.
    4. На останок, показуємо Notify messages в разі удач / невдач. Робити це будемо з допомогою: notify-send, який так само багато де вже встановлено "з коробки" (наприклад, у мене в Linux Mint)

    Тепер магія: пшпшпшпшшшшш. Все готовий, ось він скрипт: відкрити останню версію на Github

    Якщо ви поміняли вже шляху в скрипті на ваші, то залишилося додати даний скрипт в cron, для цього відкриваємо його

    Це дозволяє перевірити роботу, крім того такий запуск (з параметром force) відключає перевірку існування архівів в періоді між СБ і ЗАРАЗ. Крім того, можна задати в кроні запуск кожну хвилину (* * * * * command), почистити папку з бекамі (видалити всі файли з неї) і через хвилину, якщо все ок, бекап повинен з'явитися.

    У нас заробив ФОРУМ. Всі питання, які не стосуються статті, а так само питання по конкретно вашого випадку потрібно ставити і обговорювати саме там, в розділі "Допомога користувачам".