У меня есть виртуальный сервер, который постоянно работает, в последнее время мы пытались сделать для него резервную копию, и мы были удивлены тем, что дата модификации всех файлов изображений составляет пару недель. Мы пытаемся делать резервную копию образа виртуальной машины сервера каждые 6 часов, сохраняя при этом работоспособность сервера, но, поскольку файлы не изменяются, мы не уверены, как заставить виртуальную машину обновлять файлы сервера, чтобы мы могли создать их резервную копию.
Любые идеи?
EDIT: просто хотел добавить, что рассматриваемая виртуальная машина представляет собой образ рабочей станции Ubuntu Server VMWare.
EDIT2: снимок экрана каталога, содержащего файлы виртуальной машины, показан ниже. Обратите внимание, что мы перезапустили хост-машину 9 сентября, и с тех пор файлы не менялись, хотя виртуальная машина работает уже два дня.
Я пока не могу комментировать из-за моей оценки новичка ;-)
Чтобы запланировать моментальные снимки VMware, используйте планировщик задач Windows, настройте новую задачу для использования вашего личного входа в систему и используйте предоставленный инструмент под названием vmrum: C: \ Program Files (x86) \ VMware \ VMware Workstation
синтаксис: vmrun -T ws snapshot "c: \ my VMs \ myVM.vmx" mySnapshot
Как и все снимки, они не являются резервной копией и подвержены всевозможным ошибкам и повреждениям. По крайней мере, они влияют на производительность, поэтому я обычно их вообще не использую.
Это нормально, что отметки даты / времени не меняются, когда файл заблокирован исключительно и / или для этого файла наблюдается высокая активность диска. NTFS задерживает обновление этих записей или может не выполнять их вообще, пока виртуальная машина не будет полностью отключена VMware Workstation. Вы используете специализированный инструмент резервного копирования? Если да, это не должно быть проблемой. И, Рекс тоже прав, снимки или разностные диски - еще один естественный способ заставить VMDK оставаться статичными, поскольку все операции записи стробируются в разностный VMDK.