Prosty system backupów VM Proxmox

[RafalR]

Cześć, w ramach mojej pracy inżynierskiej przygotowałem mały system backupów i restoringu do Proxmoxa na wirtualne maszyny. 

Aktualna wersja jest już jako moja prywatna zabawa i rozwinięcie pomysłu. 

 

Skrypt jest napisany w bashu, osobiście wykorzystuję do jego realizacji zadania cron.

 

Zapraszam do obejrzenia, jeśli są osoby zainteresowane to też do wdrożenia i przetestowania.

 

Każde uwagi z chęcią poczytam, jestem ciekaw opinii albo sugestii, co mógłbym wykonać lepiej 

 

To jest ukryta treść, proszę

• Zaloguj się
• lub
• Zarejestruj się

 

[monsune]

Kurczę, jak za takie rzeczy dają dzisiaj inżyniera to chyba też muszę się zgłosić 😉

 

Widzę troszkę potencjalnych problemów. Podstawowy to taki, że nie sprawdzasz storage'a pod kątem dostępnego miejsca, a to może się głupio skończyć, zwłaszcza gdy storage jest współdzielony z przestrzenią w której działają maszyny posiadające dyski sparse. Drugi to taki, że nie został określony tmpdir, a przydałby się dedykowany pod backupy i ze względu na wydajność (przy większych systemach robi się go w ramdysku) i bezpieczeństwo całego systemu - co się stanie gdy podczas backupowania zapchasz do końca partycję systemową jakimś plikiem tymczasowym? Trzeci to skalowalność twojego rozwiązania bo jest może i do przyjęcia przy jednej, ew. kilku maszynach, gdy jeszcze ogarniasz ręcznie i mniej więcej wiesz ile czasu potrwa dany backup. A co w sytuacji, gdy trzeba ich zrobić np. 50 albo 250 i wszystkie nad ranem? Tu przydałby się system kolejkowania zadań bo gdyby tak odpaliło się z 10 instancji twojego skryptu w podobnym czasie to wolałbym tego nie widzieć np. od strony I/O.

 

Oczywiście można przyjąć optymistycznie, że żaden z tych problemów nigdy nie wystąpi u ciebie albo u innego użytkownika skryptu "bo wiedzą co robią", ale cała sztuka inżynierii/architektury systemów na tym polega, żeby przewidywać określone sytuacje i z góry im zapobiegać. Gdybym miał oceniać twoją pracę to na tym bym się skupił. Często sięgamy do gwiazd, jesteśmy kreatywni w tego typu robocie, dążymy do szybkiego efektu, a przez to tracimy kontakt z przyziemną rzeczywistością, która potrafi skutecznie sprowadzić nas na ową ziemię i to bardzo szybko, a co gorsza bardzo brzydko.

 

A w ogóle, skoro już Proxmox, to wolałbym widzieć to zrobione po API, tak byłoby bardziej inżyniersko, co nie oznacza, że lepiej bo sam bardzo lubię bash'a. Dość fajnie byłoby jeszcze wmixować tu np. rsync'a, żeby okresowo przewalać backupy gdzie indziej. Dobra, na tym zakończę chyba bo w końcu zaczniesz się doktoryzować z tych backupów 😉

 

Ogólnie duże brawa za odwagę bo łatwo jest oceniać i krytykować, trudniej coś zrobić i jeszcze się tym pochwalić publicznie.

 

 

Edytowane 26 Stycznia 2023 przez monsune

[RafalR]

2 godziny temu, monsune napisał:

Kurczę, jak za takie rzeczy dają dzisiaj inżyniera to chyba też muszę się zgłosić 😉

 

Widzę troszkę potencjalnych problemów. Podstawowy to taki, że nie sprawdzasz storage'a pod kątem dostępnego miejsca, a to może się głupio skończyć, zwłaszcza gdy storage jest współdzielony z przestrzenią w której działają maszyny posiadające dyski sparse. Drugi to taki, że nie został określony tmpdir, a przydałby się dedykowany pod backupy i ze względu na wydajność (przy większych systemach robi się go w ramdysku) i bezpieczeństwo całego systemu - co się stanie gdy podczas backupowania zapchasz do końca partycję systemową jakimś plikiem tymczasowym? Trzeci to skalowalność twojego rozwiązania bo jest może i do przyjęcia przy jednej, ew. kilku maszynach, gdy jeszcze ogarniasz ręcznie i mniej więcej wiesz ile czasu potrwa dany backup. A co w sytuacji, gdy trzeba ich zrobić np. 50 albo 250 i wszystkie nad ranem? Tu przydałby się system kolejkowania zadań bo gdyby tak odpaliło się z 10 instancji twojego skryptu w podobnym czasie to wolałbym tego nie widzieć np. od strony I/O.

 

Oczywiście można przyjąć optymistycznie, że żaden z tych problemów nigdy nie wystąpi u ciebie albo u innego użytkownika skryptu "bo wiedzą co robią", ale cała sztuka inżynierii/architektury systemów na tym polega, żeby przewidywać określone sytuacje i z góry im zapobiegać. Gdybym miał oceniać twoją pracę to na tym bym się skupił. Często sięgamy do gwiazd, jesteśmy kreatywni w tego typu robocie, dążymy do szybkiego efektu, a przez to tracimy kontakt z przyziemną rzeczywistością, która potrafi skutecznie sprowadzić nas na ową ziemię i to bardzo szybko, a co gorsza bardzo brzydko.

 

A w ogóle, skoro już Proxmox, to wolałbym widzieć to zrobione po API, tak byłoby bardziej inżyniersko, co nie oznacza, że lepiej bo sam bardzo lubię bash'a. Dość fajnie byłoby jeszcze wmixować tu np. rsync'a, żeby okresowo przewalać backupy gdzie indziej. Dobra, na tym zakończę chyba bo w końcu zaczniesz się doktoryzować z tych backupów 😉

 

Ogólnie duże brawa za odwagę bo łatwo jest oceniać i krytykować, trudniej coś zrobić i jeszcze się tym pochwalić publicznie.

 

 

Powiem tak, dzięki serdeczne! 🙂

Uczciwie mogę powiedzieć, że gdybyś zobaczył pierwszą wersję tego (i zarówno tą, która wylądowała w pracy) to zapewne załamałbyś się 🙂

Uroki pisania na ostatnią chwilę. 

 

Generalnie rozważałem kwestię chociażby rsynca i jest to w planach na dalszą przyszłość. Co do kolejkowania: tutaj rzeczywiście może być problem, gdyby doszło do takiej sytuacji, i jest to jeden z moich problemów nad którymi się zastanawiam. 

 

A i co do tego dawania inżyniera, paradoks polega na tym, że nie bronię tej pracy tylko ją daję mojemu promotorowi. Mam osobny egzamin dyplomowy wyłącznie z zestawu pytań, który nam wysłali. Ten projekt to tak jakby zaliczenie przedmiotu 🙂

 

Edit: co do api - nie ukrywam, że mam plan co do tego 🙂