Hello
Is possible to restore a single file or folder from backup proxmox without restore a full backup on a vm?
Is possible to restore a single file or folder from backup proxmox without restore a full backup on a vm?
Restore a single file from Backup
- Thread starter Dexter2305
- Start date
Sort of. Just not directly.
There are multiple methods. One of the simplest is to restore the backup to a different VMID (you do this by clicking on the name of the backup when in the backup part of the GUI for the Node rather than in the backup part of the VM.
If, like me, your VMs have static IPs, and you have software licences in the VM that do not allow more than one instance to run at once, then you need to be careful about what you do next.
Possibly the simplest option is to download a LiveCD ISO of one flavour of Linux or another, and then configure the Restored VM to boot from that. You end up with a running VM that has access to the filesystem of the backup (you would generally have to mount it manually in the temporary VM). Using rsync, scp, or even ftp, you can then transfer the file or folder to the running VM.
In my case things get more complicated here, as the security of the running VM is very high, so I have additional hoops to jump through.
Another option is to attach the restored disk on the running VM. If you use LVM, this is a problem, because you have duplicate VG names. Although there are utilities to help you with this (vgimport?), I don't like the potential danger of the wrong filesystem being written to. I wish I had not chosen to use LVM with my disk volumes.
But you can use a hybrid solution - attach the restored disk to a VM that's specifically created for restorations. This VM can have the appropriate keys, and its IP can be allowed through appropriate firewall rules, to allow you to copy files across using rsync/scp/whatever. Or you can use it (or a LiveCD) to change the VG name of the restored filesystem. I think that's all you need to make it safe to then attach directly to the running VM but I'm not 100% sure -- there may be issues with UUIDs if these don't get changed too.
Note that attaching a disk associated with one VMID to another VMID has to be done from the command line. There is no way to add an existing disk to a VM from the GUI (I don't think so anyway! If there is then I'd like to know how it is done).
Yet another option is to extract the backup and mount it on the node as a network block device.
There are multiple methods. One of the simplest is to restore the backup to a different VMID (you do this by clicking on the name of the backup when in the backup part of the GUI for the Node rather than in the backup part of the VM.
If, like me, your VMs have static IPs, and you have software licences in the VM that do not allow more than one instance to run at once, then you need to be careful about what you do next.
Possibly the simplest option is to download a LiveCD ISO of one flavour of Linux or another, and then configure the Restored VM to boot from that. You end up with a running VM that has access to the filesystem of the backup (you would generally have to mount it manually in the temporary VM). Using rsync, scp, or even ftp, you can then transfer the file or folder to the running VM.
In my case things get more complicated here, as the security of the running VM is very high, so I have additional hoops to jump through.
Another option is to attach the restored disk on the running VM. If you use LVM, this is a problem, because you have duplicate VG names. Although there are utilities to help you with this (vgimport?), I don't like the potential danger of the wrong filesystem being written to. I wish I had not chosen to use LVM with my disk volumes.
But you can use a hybrid solution - attach the restored disk to a VM that's specifically created for restorations. This VM can have the appropriate keys, and its IP can be allowed through appropriate firewall rules, to allow you to copy files across using rsync/scp/whatever. Or you can use it (or a LiveCD) to change the VG name of the restored filesystem. I think that's all you need to make it safe to then attach directly to the running VM but I'm not 100% sure -- there may be issues with UUIDs if these don't get changed too.
Note that attaching a disk associated with one VMID to another VMID has to be done from the command line. There is no way to add an existing disk to a VM from the GUI (I don't think so anyway! If there is then I'd like to know how it is done).
Yet another option is to extract the backup and mount it on the node as a network block device.
Hi
If restore the backup in another vm is not comfortable because it takes time and lots of hardware resources, because if the host has 8 GB of ram and the vm takes 6 GB if restore in another vm the backup and run the second vm to copy file the host are in difficulty between ram and cpu use.
So if there was a method to restore the backup maybe in a storage and then copy the files I need from the backup.
Or better if it was possible to mount the backup and copy the folders or files I need.
If restore the backup in another vm is not comfortable because it takes time and lots of hardware resources, because if the host has 8 GB of ram and the vm takes 6 GB if restore in another vm the backup and run the second vm to copy file the host are in difficulty between ram and cpu use.
So if there was a method to restore the backup maybe in a storage and then copy the files I need from the backup.
Or better if it was possible to mount the backup and copy the folders or files I need.
You don't need the Restoration VM to have the same resources as the real one. It only needs enough RAM to run Linux. 512Kb is usually enough. You can even get away with less, potentially.
However, if you want to mount the backup on the Node, here are my notes about how to do so using NBD:
Extract .vma from .lzo backup:
# lzo -x backupname
Now extract .raw from .vma and save it in targetdir
# vma extract filename.vma targetdir
[The downside of this is that you now have the original backup, the non-compressed backup, and the .raw. Three versions of the same file! This takes up disk space!]
Now we want to mount it with the help of nbd
# modprobe nbd max_part=63
[We don't really need 63 partitions but that's what always seems to be used]
# qemu-nbd -f raw -c /dev/nbd0 restored.raw
# mkdir /mnt/img
If not using LVM:
# mount /dev/nbd0p1 /mnt/image
[Where p1 means partition 1. If you need partition 2 you would use p2 etc etc]
If using LVM, before mounting you will want to run vgscan to find the VG, then vgchange -ay vgname to activate it, and then mount it as /dev/vgname/root (or whatever) rather than as /dev/nbd0p1]
Now you can work with the mounted image on the Node so you can copy your files and directories.
When you are finished:
# umount /mnt/image (or whatever you mounted it)
if using LVM: vgchange -an vgname
# qmenu-ndb -d /dev/nbd0
# rmmod nbd
[if necessary, killall qemu-nbd ]
And finally delete the extracted .raw and .vma.
NOTE: Someone commented to me that you can directly mount a .vma. I did not do so and don't know what additional steps are required, if any. Maybe I misunderstood. Or naybe someone can tell us.
Also I have not tested the above with LVM. See https://projects.letic.fr/projects/public/wiki/Proxmox_KVM_Restore_files
However, if you want to mount the backup on the Node, here are my notes about how to do so using NBD:
Extract .vma from .lzo backup:
# lzo -x backupname
Now extract .raw from .vma and save it in targetdir
# vma extract filename.vma targetdir
[The downside of this is that you now have the original backup, the non-compressed backup, and the .raw. Three versions of the same file! This takes up disk space!]
Now we want to mount it with the help of nbd
# modprobe nbd max_part=63
[We don't really need 63 partitions but that's what always seems to be used]
# qemu-nbd -f raw -c /dev/nbd0 restored.raw
# mkdir /mnt/img
If not using LVM:
# mount /dev/nbd0p1 /mnt/image
[Where p1 means partition 1. If you need partition 2 you would use p2 etc etc]
If using LVM, before mounting you will want to run vgscan to find the VG, then vgchange -ay vgname to activate it, and then mount it as /dev/vgname/root (or whatever) rather than as /dev/nbd0p1]
Now you can work with the mounted image on the Node so you can copy your files and directories.
When you are finished:
# umount /mnt/image (or whatever you mounted it)
if using LVM: vgchange -an vgname
# qmenu-ndb -d /dev/nbd0
# rmmod nbd
[if necessary, killall qemu-nbd ]
And finally delete the extracted .raw and .vma.
NOTE: Someone commented to me that you can directly mount a .vma. I did not do so and don't know what additional steps are required, if any. Maybe I misunderstood. Or naybe someone can tell us.
Also I have not tested the above with LVM. See https://projects.letic.fr/projects/public/wiki/Proxmox_KVM_Restore_files
Hi and thanks for reply
HI read your message the proccess is not simple and he takes a lot of disk space and time, i think proxmox can you implement a function in the web gui to explore the backup and restore what you want.
Maybe it already exist but we don't know.
HI read your message the proccess is not simple and he takes a lot of disk space and time, i think proxmox can you implement a function in the web gui to explore the backup and restore what you want.
Maybe it already exist but we don't know.
I would love to see the same functionality you want.
But the difficulty in achieving it is too great for this to ever happen as far as I can ever imagine.
So, how about backing up your data in a different way?
I have been investigating this myself.
For me, firstly the backup must be to Amazon S3, because I don't want to waste space on local storage.
Secondly, it must not involve creating large local archives within the VM, because that doubles the amount of space you have to allocate to the VM. Instead I want backup of files streamed to the backup location. This isn't suitable for every application, but it fine for being able to restore a file or directory if required.
Baccula and similar are too complex. Old School. Not for me.
I like backupninja because it is just so simple, but there seems to be some issue with it not being developed anymore or something like that.
But of course there is also the very new kid on the block: duplicity. This may be the ideal solution. I strongly suggest you look into it. There are many howtos and suggestions for using it to backup to s3, Google Drive and so on.
But the difficulty in achieving it is too great for this to ever happen as far as I can ever imagine.
So, how about backing up your data in a different way?
I have been investigating this myself.
For me, firstly the backup must be to Amazon S3, because I don't want to waste space on local storage.
Secondly, it must not involve creating large local archives within the VM, because that doubles the amount of space you have to allocate to the VM. Instead I want backup of files streamed to the backup location. This isn't suitable for every application, but it fine for being able to restore a file or directory if required.
Baccula and similar are too complex. Old School. Not for me.
I like backupninja because it is just so simple, but there seems to be some issue with it not being developed anymore or something like that.
But of course there is also the very new kid on the block: duplicity. This may be the ideal solution. I strongly suggest you look into it. There are many howtos and suggestions for using it to backup to s3, Google Drive and so on.
So you me advice to mantain the ingrated backup in proxmox to backup the full vm, and use command duplicity to backup (documents,pictures,etcetc) right?