Is there any software to make a perfect image of a running Linux system?

As I see it, something like Timeshift (rsync based) has no method to ensure all files are copied when in a consistent state- i.e. no way to copy all files as they exist in the same instant of time.

A solution based on a ZFS or BTRFS file system snapshot solves this, but still it doesn't account for what code is running at that time - so isn't it possible that although the disc is a perfect snapshot, if something was 'in the offing' on the processor that was about to make another modification it would cause a problem if this snapshot (minus processor state) was re-imaged.

Please let me know if I have any misconceptions here, and how can I make an exact snapshot of a running system that will not have any potential inconsistencies with the aim of imaging this to an identical machine if the first encounters hardware problems.

I'm running Linux Mint but this is not a Mint/Ubuntu specific question.

Thanks in advance.

I think you need to define what you mean by a "perfect image" ?

The only way I know of to backup a Linux system (or any other system) would be to use backup/cloning software of some description. If your talking about backing up a system including what's in memory and while it's running...

You can't backup everything while the system is running. For example, files that are "in use" may not be able to be backed up.

If I'm understanding your question correctly, I don't think there is any "perfect" solution that members could suggest to you.

Why not just use hard drive based cloning software?

1 members found this post helpful.

The issue here is obtaining a snapshot of the system that is guaranteed to run without error if reinstated on the same hardware. (Assumptions: source system is not corrupt at time of imaging, no disc errors, no memory errors.)

Hard drive cloning software AFAIK does not answer the question of the running system and consistency thereof.

Is there anything similar to the volume shadow copy service on Windows, as an example?
https://technet.microsoft.com/en-us/.../ee923636.aspx

Linux snaps use filesystem freeze to ensure consistency on-disk. This generally works sufficiently, but database systems are a problem child. AFAIK, they still need to be closed and forced to disk. Same for anything else that directly manages its own I/O (direct or async I/O).
Transaction roll-back would maybe help in this case.

OpenSuSE snapper excludes portions of the filesystem(s) from snaps for rollback - see their reference manual for their reasons.

1 members found this post helpful.

Well, once again, there is no "perfect" solution, it depends on your requirements.

Typing into Google the following will give you a number of options to look at, "volume shadow copy like software for linux".

https://unix.stackexchange.com/quest...nternal-backup
https://serverfault.com/questions/23...-shadow-copies

The above is just two of them.

You should also understand that Linux is not Windows, there are fundamental differences between them.

Once again, hard drive cloning software should do what your asking for. This should make an exact copy of your system.

Maybe you should explain why you need a copy of a "running system" and more to the point why cloning software would not archive a similar result?

If you make a "clone" of your system, it's still going to make an exact copy of it, as it currently stands.

1 members found this post helpful.

Thanks a lot syg. That's useful information and I will take a look at the reference you mention.

Curious...

Just this week I had my primary harddrive with kernel and home directories have read errors.

Long story short (With a happy ending.)

I had another drive not the same size that I plugged into another linux system and partitioned accordingly.

I create an ext4 partition of a size that the files from failing partition could be copied over to with rsync.
I create the swap partition that would be needed.

Grub2 was installed on the new hard drive.

/etc/fstab was edited for the root partition using the correct /dev/sdaX entry instead of the old partition UUID.

I rebooted into the new hard drive and Grub2 did come up. Grub2 was able to bring up menu entries but from the previous systems /boot/default/grub.cfg

The main entry was edited and for the linux command within that entry, I removed the UUID for the root partition and replaced it with the /dev/sdaX

I was able to boot into the system and run "update-grub". This step would fix the /boot/default/grub.cfg to have the correct UUID for the root partition and swap partition.

I ran "blkid" to get the UUID for the new hard drives root partition and swap partition.

/etc/fstab was then replaced with the new UUID for the hard drive.

I rebooted and voila, my system is back up and running off the new hard drive. Working perfectly.

A test that I have not done is to then clone this hard drive with dd to create an image on another hard drive.
I am assuming that the image now would be perfect.

Things to consider are size of the new hard drive. I kept it small so cloning with dd would be small too. 30GB for example.

Why did I not try dd in the first place? (I actually tried it. Grub2 was only seeing a corrupted /boot/default/grub.cfg

1. My existing hard drive image would be too big to clone the entire drive.
2. Read errors would have shown up in the clone.

I kind of gave the quick description of what has worked for me.

It does not seem like what exactly you are looking to do, let me know if it might be thou.

1 members found this post helpful.

While it's not a 100% guarantee, I have never had rsync fail me. Let me explain.

I use a number of systems with a "ramboot" hack. It involves a modification to initrd so that it copies the OS partition into a tmpfs file system in RAM. Then it continues to boot. I use rsync to copy the current tmpfs file system back over to the hard drive copy.

I do this while the system is running, including a GUI desktop environment and also various applications. The result is something similar to what would happen if the power suddenly cut out at the time I rsync. It's not 100% exactly the same, because files are copied over the course of a few seconds rather than at a specific instant in time.

But it works just fine. Each and every time.

Basically, all software is written keeping in mind the fact that the power could cut out at any time. Software which is badly written could, indeed, have bad errors if the power cuts out. But this is such a common failure mode that most software isn't written that badly.

An rsync pseudo-snapshot which copies over files across some seconds rather than an instant cutoff is close enough to a power failure that linux software is okay with it.

1 members found this post helpful.

More good info- thanks chaps.

I suspected rsync was usually 'good enough' as I don't see people complaining about problems with Timeshift used to image running systems. A file system that offers snapshots is then a step up from this and beyond that would be something where applications are 'snapshot aware' and can be signalled to get their affairs in order ahead of an impending snapshot (flushing to disc, consistent database states etc.)

So Isaac, why do you run from a tmpfs file system rather than, say, booting normally and just syncing to another directory? Sounds interesting.

I use "RAMBOOT" for speed and silence, mainly. If you have a system with a good amount of RAM, it's even faster than an SSD. OTOH, if your computer is modern enough to have a USB3.0 port, you can get a really cheap USB3.0 thumbdrive that has pretty decent performance (slow by SSD standards, but still not bad).

RAMBOOT is mostly a good fit for laptops without USB3.0 ports.

NFS-RAMBOOT is a variant which loads an OS tarball from an nfs share (I still use rsync to copy back over to a normal file system tree; the use of a compressed tarball is just to make it load up faster over the network). Once the OS is loaded up, the laptop can be unplugged from the ethernet network. This is an interesting way to harden your laptop from potential attackers. Since the OS is strictly in RAM, it's impossible to just reboot the computer via liveCD or liveUSB to access the OS file system.

Alternatively, NFS-RAMBOOT is a good fit for a laptop or tablet PC which uses weird hard drive sizes or doesn't have a required caddy/cable. RAMBOOT off of USB also works.

NFS-RAMBOOT can also be a good fit when you have a lot of client computers but you only want to maintain one standard OS image.

That said, for fixed computers that are attached by gigabit ethernet, it generally makes more sense to use nfs-root rather than consuming a chunk of RAM on local storage of the OS file system. A single SSD or USB3.0 thumbdrive can store nfs-root for many computers, especially using btrfs (which can dedupe files).

Thanks for the detailed response, Isaac. Interesting possibilities I had never even considered. Sounds like it might be complicated to set up, though!

I have detailed how-to instructions for RAMBOOT (with rsync) and NFS-RAMBOOT on my LinuxQuestions blog, as well as NFS root (which requires no custom initrd script code). I have refined and simplified things over the years.

https://www.linuxquestions.org/quest...aackuo-112178/

1 members found this post helpful.

Dude, much appreciated. I will read with interest.

I have an example of backup script that takes LVM snapshot then rsync it to NFS server.
Linux backup
Please do not leave backup NFS mounted. I've heard about someone did "rm -rf /" including it's (mounted) NFS backup server.

Cheers Voleg!