- це був в vds_snapshot.vss
diskshadow / s vds_snapshot.vss
- з'являється диск N
його копіюємо чим завгодно, я використовую
rar64 a -x * .bin -dh -m1 -md64 -mt4 -r
потім
delete shadows all
unexpose N:
unexpose M:
- це теж .vss і теж в diskshadow / s - диск зноситься
дуже дешево і дуже сердито, але 100% контроль над процесом, і при наявності прямих рук і бажання написати cmd на десяток рядків - оптимальний, хороший, надійний бекап.
А якщо віртуальні машини не на окремому томі?
І що таке writer в термінах VSS?
якщо не на окремому томі, то add volume потрібні томи
це в общем-то не важливо, якщо чогось не так, воно просто не спрацює і це буде очевидно видно.
writer - це плагіни для отримання більш сумісних або оптимальних бекапов за допомогою обліку определнного підсистем
наприклад, writer для SQL-я бекапіт по чекпоінти бази, wirter для temp не копіює temp-каталоги, і так далі
writer для HV серверів - проводить консультації з shadow-службами всередині машин і намагається рекурсивно запустити writer-и в кожній машині окремо, щоб в результаті, наприклад, вийшов сумісний бекап SQL сервера, що працює в HV-машині
практика така, що якщо включити все writer-и, то все це періодично клинить і взагалі не бекап, тому я не користуюся writer-и, виходить просто тупий апаратний снапшот а-ля lvm, чого достатньо за великим рахунком для адекватного збереження даних
Так машини жеж в занедбаному стані знаходяться, якщо зробити в цей момент snapshot, машини потім можуть і не злетіти, після відновлення.
Якщо у вас машини можуть не злетіти після відключення живлення сервера, або синього екрану Ноди, або reset-а, то навіщо взагалі жити на цьому світі?
Якщо на те пішло, то зробити зовнішній бекап linux-машини усередині HV взагалі неможливо, тому що підтримки VSS там немає і не буде (там взагалі такої концепції немає, тільки окремі милиці типу xfs_freeze). Зробити бекап з повною підтримкою VSS коли небудь машин більше декількох, або машина пройшла складний життєвий шлях довше декількох немає, теж зазвичай не виходить - все висне, клинить, розсипається.
Зробити "нормальний" бекап mySQL крім як за допомогою mysql_dump ВЗАГАЛІ ніяк не можна.
і так далі
Acronis або штатний бекап будуть це робити через точно той же самий непрацюючий VSS (замовчування), або без нього (в Acronis спеціально є така опція, тому що з нею він на складному сервері взагалі частіше бекап навіть запустити не може, ніж взагалі хоч байт сбекапіт ).
У простому посектороном бекапе снапшотов сховища, який ви отримуєте через VSS, хоч з writer-ами (якщо пощастить), хоч без (як я раджу), у вас буде рівно таку ж якість інформації, як після зникнення живлення сервера або його reset-а , навіть краще, тому що не буде проблемою + -дісковий кеш.
Якщо ваші системи після таких подій не піднімаються, такий бекап, звичайно, не підходить. Наприклад, дійсно, для прикладу, може зламатися mySQL. Але це проблеми в консерваторія окремих додатків, і ЗАГАЛЬНИЙ рішення бекапа їх ніколи не вирішить, наприклад, див. Вище, загального принципу бекапа mySQL взагалі не існує, і нічого.
Ні, я до того, що якщо відключити VSS writer для Hyper-V, який в змозі сказати віртуалкою: "Готуйся! Щас будемо бекапіть!", То фактично виходить, що в бекапе буде просто якийсь снепшот дисків віртуальних машин, причому запущених віртуальних машин . А коли ми це все з резервної копії відновимо, то система спочатку буде змушена завантажитися. Чи злетить воно в таких умовах? Хоча з іншого боку, у нас там XP і Win7, ці начебто не повинні відчувати великих проблем.
Ну про консистентность см. Вище. Спробуйте просто не виключати writer-и. Подивіться що буде. Коли заклинить - тоді і виключайте по одному, поки не запрацює. Якщо у вас є моніторинг бекапа, це дуже ОК, але ви повинні якось знати про те, що бекап перестало.
Штатний бекапер знову ж, чи Acronis, можливості виключити writer-и по одному вам не дасть.
А геморой з відновленням вирішується двома способами: або віддати 40 тис. Acronis-у або куди ще, або штатний бекап і сподіватися, що всі існуючі VSS writer-и будуть працювати штатно і нічого не повисне.
І я так розумію, що так можна сбекапіть тільки виртуалки, які підтримують VSS внутрі. Решта потрібно попередньо стопити. І як щодо мета-даних в віртуальних машинах - всі ці настройки обладнання та інше - воно ж десь в іншому місці на зразок зберігається.
див. вище
якщо хочеться бекапіть за допомогою VSS всередині, не виключайте їх writer-и.
Але це черевато тим, що якщо десь щось всередині повисло, то взагалі нічого ні в кого не сбекапітся.
Нормальний миттєвий снапшот рівня зберігання виходить навіть в тому випадку, якщо "підтримки VSS" ніде в помині немає (тобто немає підтримки жодного writer-а або все writer-и виключені).