How to backup and restore a VM

[Louis2]

I do not understand what you are trying to say.

I hope / think that is working as long as the intention is not to create a stand alone backup (I did not test)

However ... it should work ...... and I do want to have a separate backup file for ... you never know ...

So, I am not happy before I have a working solution !!

 

[Arwen]

If you want a backup file, not a backup zVol, it is FAR easier;

Stop the VM if you want a clean backup.

sudo su - zfs snapshot Cheetah/Virtual-Machines/xyz@20230422 zfs send -v Cheetah/Virtual-Machines/xyz@20230422 >/mnt/Olifant/BackUp-VMs/xyz.zfs

When done, you clean out the snapshot;

zfs destroy Cheetah/Virtual-Machines/xyz@20230422

You can even pipeline compress it;

zfs send -v Cheetah/Virtual-Machines/xyz@20230422 | gzip -c9v >/mnt/Olifant/BackUp-VMs/xyz.zfs.gz


Edit: Fixed the "grep" typo with "gzip".

 

[Louis2]

Nothing against a file, ....... as long as I can use the file to restore the zvol of the vm if necessary ....

 

[NugentS]

I started looking at this - and immediately wandered into the TrueNAS CLI

"service vm query" will list, in way too much detail the VM's running
"service vm stop 'n'" will stop a VM
"service clone 'n'" will clone a VM
"service vm start 'n'" will start a VM
[N.B. These command are not shell, but CLI]

Testing of stop indicates a clean shutdown in progress - I just have a stupid app in the VM that requires a long time to shutdown. However the stop command does return a 100% well before the VM is actually shutdown. This I would describe as a bug allbeit not a major one.

Testing of clone creates a clone of the zvol in the same dataset

Testing of start does do a start - works just fine

On the subject of the clone:

1. Note the size of the clone in comparison to the original. This would imply to me that its a snapshot clone (is that the right phrase) rather than a full clone
2. Its a very quick operation - a few seconds
3. Under virtualisation (GUI) I get

So what I thought was how about writing a script to do the following:

1. Stop a VM
2. Clone a VM
3. Start a VM
4. Replicate the cloned zvol as a backup - that way I should get an application-consistent backup as opposed to a crash-consistent backup
5. Delete the clone

Note that every time you clone a VM it clones to a new VM BUT the ID is incremented by one (this will probably reset on a reboot), even if you delete a previous clone. I can forsee the need to search the service vm query output to find the source VM and then search it again for the clone name so the zvol can be replicated.

The CLI commands can be run from the bash prompt as

Code:

cli -c "service vm query"

which will produce the output

Code:

+----+---------------------+---------------------+-------+--------+------------+-----------+-------+------------+-------+---------+-----------------------+------------------+------------+-----------+--------+---------+-----------+---------------+---------------------+-----------------------+-----------+--------------+--------------------------------------+-------------------+-----------------+-------------------------+---------+--------+
| id | name                | description         | vcpus | memory | min_memory | autostart | time  | bootloader | cores | threads | hyperv_enlightenments | shutdown_timeout | cpu_mode   | cpu_model | cpuset | nodeset | pin_vcpus | hide_from_msr | suspend_on_snapshot | ensure_display_device | arch_type | machine_type | uuid                                 | command_line_args | bootloader_ovmf | trusted_platform_module | devices | status |
+----+---------------------+---------------------+-------+--------+------------+-----------+-------+------------+-------+---------+-----------------------+------------------+------------+-----------+--------+---------+-----------+---------------+---------------------+-----------------------+-----------+--------------+--------------------------------------+-------------------+-----------------+-------------------------+---------+--------+
| 2  | Ubuntu_Docker_20_04 | Ubuntu_Docker_20_04 | 4     | 16384  | <null>     | true      | LOCAL | UEFI       | 2     | 1       | false                 | 90               | HOST-MODEL | <null>    | <null> | <null>  | false     | false         | false               | true                  | <null>    | <null>       | b4f582a7-bcba-4e84-ba42-a8d8738b019b |                   | OVMF_CODE.fd    | false                   | <list>  | <dict> |
+----+---------------------+---------------------+-------+--------+------------+-----------+-------+------------+-------+---------+-----------------------+------------------+------------+-----------+--------+---------+-----------+---------------+---------------------+-----------------------+-----------+--------------+--------------------------------------+-------------------+-----------------+-------------------------+---------+--------+

Which if it didn't wrap around on the screen would be great - as it is its less than 100% human readable, not that it really needs to be

 

[NugentS]

Continuing this - this would imply that the script logic would be something like:

Code:

run "service vm query"
search output for ID & VMName. Reject any with clone in the name. Put results into array
Loop through the array
    shutdown vm.
    delay to complete shutdown.
    clone vm
    start vm
    work out zvol name for clone
    replicate clone zvol to file or other dataset - whatever
    delete clone
end loop

Thoughts:

1. Would suspend be acceptable rather than shutdown. Suspend is almost immediate - no delay. Resume is also effectively immediate VM is effectively quiesed in a suspended state so backup should be good. Power off is safer, I think, assuming the damned VM's actually shutdown - but suspend seems more reliable
2. Do I need to worry about cloning when the VM is shutdown. Why not just replicate the zvol directly? It does mean the VM doesn't start up quite so quickly.

 

[Arwen]

If the Clone VM makes a ZFS snapshot, (and it seems to because both it's fast, and starts off using little space), then why bother with the Cone VM part?

It's the ZFS snapshot that holds 100% of the VM's data at the time of the snapshot.

 

[NugentS]

@Arwen you are correct - I hadn't thought it through properly - which was the reason for posting it

So

Code:

run "service vm query"
search output for ID & VMName - put in array
Loop through the array
    shutdown vm (or suspend)
    delay to complete shutdown.
    snapshot & replicate vm
    start (or resume) vm
end loop

 

[Louis2]

Oeps!! I discovered what I did wrong !!

I was using a snapshot of the data set, where I should have made a snapshot of the zvol used by the VM !

root@lion[~]# zfs snapshot Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1

zfs send -v Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1 | zfs receive -ev Olifant/BackUp-VMs/BSDTEST2
full send of Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1 estimated size is 1.70G
total estimated size is 1.70G
receiving full stream of Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1 into Olifant/BackUp-VMs/BSDTEST2/FreeBSD14-yle96l_FreeBSD14_20230401a@test1
TIME SENT SNAPSHOT Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1
09:24:37 417M Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1
09:24:38 911M Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1
09:24:39 1.36G Cheetah/Virtual-Machines/FreeBSD14/FreeBSD14-yle96l_FreeBSD14_20230401a@test1
received 1.69G stream in 8 seconds (216M/sec)

I think its OK 1GiB is not much, but it is a minimal FreeBSD-install, so it could be correct (I did not yet test it). A bit strange the original ZVOL was much bigger.

Sorry for this stupid error/problem!
Thanks for the support !

 

[Louis2]

I hope that the result above is correct. Assuming that for the moment the procedure I followed is described below.
Very very annoying the extremely long names ...... with the relevant part at the right (=wrong ) side ....

 

[Arwen]

You don't really want the "-v" on both Send & Receive. The output would be confusing. Pick one side.

Also, their is probably a ZFS snapshot on the destination too; You can see it with;
zfs list -t all -r Olifant/BackUp-VMs/xyz/

Glad you figured it out. Most of what we sent you should have worked. But, sending a single, mostly empty, dataset would result in little data being sent. Hopefully ZFS Send & Receive will be much clearer for you now.

Remember, if your goal is pure backups, you don't need the ZFS Receive part. Just create a file, perhaps in a compressed pipeline like I showed you. You can always use that file as the source of a ZFS Receive;
zfs receive -ve Cheetah/Virtual-Machines/xyz </PATH/TO/ZFS_Send_file

 

[beagle]

If you want a backup file, not a backup zVol, it is FAR easier;

Stop the VM if you want a clean backup.

sudo su - zfs snapshot Cheetah/Virtual-Machines/xyz@20230422 zfs send -v Cheetah/Virtual-Machines/xyz@20230422 >/mnt/Olifant/BackUp-VMs/xyz.zfs

When done, you clean out the snapshot;

zfs destroy Cheetah/Virtual-Machines/xyz@20230422

You can even pipeline compress it;

zfs send -v Cheetah/Virtual-Machines/xyz@20230422 | grep -c9v >/mnt/Olifant/BackUp-VMs/xyz.zfs.gz

Hi @Arwen ,

I was wondering if you meant gzip instead of grep on the last step:

zfs send -v Cheetah/Virtual-Machines/xyz@20230422 | gzip -c9v >/mnt/Olifant/BackUp-VMs/xyz.zfs.gz

 

[Arwen]

Hi @Arwen ,

I was wondering if you meant gzip instead of grep on the last step:

zfs send -v Cheetah/Virtual-Machines/xyz@20230422 | gzip -c9v >/mnt/Olifant/BackUp-VMs/xyz.zfs.gz

Yes, thank you. I've edited the post to reflect the correction.