Vbl proovida ka kettaimage backuppimist debiani seest, see on üks võimalik kasutusstsenaarium. Img backupi korral võib mõelda ka kuidas tulevikus tekitada snapshot, et backup tehtaks hetkeseisust. Kuna backup hakkab asuma võõral pinnal (Tartu LV), siis igasugu ISKE norimiste vähendamiseks pigem tõesti kõik backupid krüptida. Võti siis ntx serverispetsiifiline, aga mul pole praegu head mõtet kus seda genereerida ja hoida. Võti peab olema kiirelt kättesaadav kui masin hävinud. Mõne masina, mis pole nii sõgedalt tillukesi faile täis kui nw/havi/mailedu, peal veel testida? Muheleja /home? Postimaja? Havidb? Borgi puhul iga masin tuleb panna eraldi reposse jah, sest repo objekte indekseeritakse mh backuppivas masinas endas. Kui vabrikusse borgi partial teha, siis 1) BORG_CACHE_DIR panna ntx /srv/.borg peale, 2) backuppida kogu /srv, kuid 3) excludida /srv/.borg. Praegu kord kuus tehtav full-backup (vs incremential) on edaspidi vast tõesti asendatav kord kuus tehtava "check"-iga. Heal juhul meil tekivad (asenduvad) edaspidi backuppimise töövahendid % vabriku masinate backup partial % linux masina tervenisti backuppimise skript % proxmoxi sees ketta image backupi skript % backuppide igapäevane olemasolu kontroll, kas lärmakas või vaikne % backuppide perioodiline põhjalikum kontroll (ntx borg check, või meie varasem plaan mõõta backupi mahtu kettal) @ juhend uue masina lisamiseks varundajasse @ kliendile backupi exe paigaldamise juhend @ taastamise juhend - kogu masina taaste @ taastamise juhend - üksikute failide või kataloogide õngitsemine Juhendid ei pea pikad olema, mida lühem seda parem. Ideaalne tarkvara (kui selline on üldse olemas) ei vaja juhendit Võib juhtuda, et superhead softi ei leiagi ja jätkame rsynciga. Töövahendid on meil üldiselt olemas, kuid täiuslikkusest lahutab paar sammu. Veel üks nice-to-have featuur mõtlemiseks - write-only backup, s.t. backuppiv masin ei saa hävitada juba tehtud varukoopiaid. (Windowsi cryptolocker viirus üritab pekki keerata ka backupi failid).