Hello,
is there a way to backup image of system without taking out SD card directly in Raspbian. For example on network drive like NAS or on USB-Flash?
Also one wish: image must be compressed, i mean - the size of image must be not the total size of SD card (for example 64Gb) but only the actual size of the Raspbian with all files (for example 2-6Gb) so if something fails i can write image again on another SD card and start system, without any installations?
Thanks!
No, because Linux is a multi-user system with processes always changing files.
You should only need your application, configuration, & data files anyway. It is usually preferred to install the OS fresh.
And mqtt brocker and zigbee2mqtt and so on everytime fresh, every time about 2-3 Hours? Really no way or only take out the card and make a image?
Even if you shut down OH & mqtt broker, OS processes like ssh, network, printing, email, filtsystem mounting, and system init are running along with other OS kernel processes.
@Bruce_Osborne you might want to look into file system snapshots (btrfs, zfs, apfs, …) 
@thisisIO You can find a simple script, which uses rsync to backup to an .img file here, I use something like this to backup to my NAS.
Or you can use a more sophisticated backup solution like Amanda, take a look at How to backup your openHABian server using Amanda.
Thanks!
Is it complete image but compressed to the size of files? And can be easly recovered?
It is a sparse file, so the actual size will depend on the file system it’s written to. The script supports compression, but I’d rather make incremental backups.
You can write it to an sd-card like any other image.
I remotely backup my complete system from my Mac with dd, e.g.
ssh openhabian@192.168.x.xx “sudo dd if=/dev/mmcblk0 bs=1M | gzip -” | dd of=/File/Path/on/local/disk/openhabian_Backup.gz
which gives me a compressed zipped backup of the whole SD card.
You just need to make sure that the user openhabian has NOPASSWD rights to /bin/dd in your sudoer file. If something goes wrong this image can be written back to the SD card - not remotely though 
- and all is up and running again.
@thisisIO one more thing: What @Bruce_Osborne said does apply to this backup method, if you want an exact copy of a specific point in time, you either need a filesystem that supports snapshots or remove the card and make an image. But this should still be good enough to get you up and running again.
Using rsync should be a lot faster, especially for incremental backups and less error-prone.
Possibly if the open files are not critical to operation.
I’m don’t know to what extend dd or rsync are available on windows. Some quick googling seems to indicate that there are existing solutions.
No no not for backiping windows, but to backup taspi from windows)
We’re talking rsync not dd, it shouldn’t matter if a file is open or not.
Your method is running dd on the pi anyway, so how does it matter if it’s available on windows?
But I would not recommend this method on a running system.
True but I was thinking more about your rsync suggestion. While I am aware of the open files issue I have to say that this has been working nicely for me for several years now.
So this script https://github.com/lzkelley/bkup_rpimage is not sensible to running system?
Is it an image, that i can easy write on new SD (for example in windows with balenaEtcher) and put in raspi and it will work? Or is there other way to restore this backup?
I know, I’ve done the same thing in the past tbh 
The main reason I’m using rsync is that it’s much faster to make an incremental backup.
That should work, yes and I’ve done it in the past. But this is inevitably not as reliable as a “real” backup solution like Amanda.
A quick glance at the script seems to indicate that it also uses dd for the initial image creation. It also indicates the same as we have talked about here: " The backup is taken while the system is up, so it’s a good idea to stop programs and services which modifies the filesystem and needed a consistant stateof their file."
But why? Some files can crash and system does not start?
Also a question - it make a image of whole card with the size of a card, not the size of actual files?
That’s not easy to answer. If you’re backing up to the same image every day you might backup files that are already corrupted without noticing it, for example. A proper backup solution will store a history of files and should allow you to go back to a working state.
It’s a sparse file. If your file system supports sparse files, the size of the image will depend on the actual content. So if you’re using 4GB of a 16GB card, the image will be around 4GB.