Hi all,
I'm starting experimenting a little bit of overclocking for my Raspberry Pi2 with OMV.
The only way I know to have a disaster recovery solution is to shutdown omv,plug the microSD into my macbook, make an image file using dd.
If something get corrupted during the day I can quickly (not really quickly, dd is really slow with 8GB image) restore all again via dd (image -> microSd).
But how can I backup my omv instance live, while it's running in a way that is automatic and allow me to do a quick restore in case of emergency?
I have an external usb drive attached to the rpi and also a remote share mounted (coming from an usb drive attached to the router)
Disaster recovery backup
-
- OMV 2.x
- mcgyver83
-
-
Quick restore? you can't. Does that much change from your image that it wouldn't work anymore?
-
I have to shut down each evening the system, go downstairs, take the microsd and so on...
I'm looking something that, once a day, can produce "an image" that I can restore quickly. -
-
I run dd on cron. It makes an image daily @3:00am when the machine is not in use. I keep a week's worth of backups. This is entirely automated. However, restoring from a backup is not trivial.
Yes, using dd to backup a live system can lead to some inconsistencies in the backup, but in my use case they would be minor and unimportant.
-
I don't have critical data on the microSD,so minor inconsistencies could be accepted.
What do you mean as "not in use"?
I have jdownloader, mysql, wordpress, emby running on the system, could be hard to stop all of them at certain time, dd and restart all again.
Could I use dd while this system is running?
Mysql db, wordpress files, jdwonloader download file, emby cache and database are all on an usb drive, so from what I know only log service is writing during the night -
"Not in use" means at 3:00am nobody is using any of the services that are running on the machine. Again, people will say not to use dd on a running system. But I understand the implications of doing so and choose to do it anyway.
-
-
Ok, but as said I'm not having critical services running, do you think coul be safe to do with dd?
-
Using dd to make an image from a disk isn't dangerous. You just may not get a working image if the system is too busy.
-
Ok, so I can try and see what happens.. So there isn't another way to achieve my goal to have a scheduled backup of running system with 100% of confidence...
-
-
Sure there is. You would need to have the OS partition on LVM or btrfs. Then you could snapshot it. Is it worth it? Probably not. So, use dd because it is good enough. If you have mission critical stuff on an RPi, then something else is wrong in your plan.
-
You are right, lets try dd.
Any suggestion on important/useful dd option to speed up the process?
To dd from 8GB microSD to ssd mac drive took 2 hours and the restore process almost the same... -
Did you set the block size? bs=1M
-
-
At the end I tried with bs=4096 but I made some test with pv using bs=1M, bs=2M, bs=512 and also using osx rdisks (raw disks) instead of /dev/disk but transfer speed was around 1MB/sec on a Sandisk class 10 16GB microSD
-
That is really low. I always use bs=1M and get 3MB/sec on cheaper SD cards up to around 15 MB/sec on better SD cards.
I use this reader
https://www.amazon.com/gp/prod…_detailpage?ie=UTF8&psc=1I usually use UHS-1 cards like
https://www.amazon.com/gp/prod…_detailpage?ie=UTF8&psc=1
https://www.amazon.com/gp/prod…_detailpage?ie=UTF8&psc=1I don't have any good cards right now. So, I couldn't tell you which are faster or slower.
-
Probably I found the mistake: the dd params should be bs=1m not bs=1M.
As soon as possible I try the dd backup script.
-
-
No, it's uppercase: M
From the dd man page:
BLOCKS and BYTES may be followed by the following multiplicative suffixes: c =1, w =2, b =512, kB =1000, K =1024, MB
=1000*1000, M =1024*1024, xM =M GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!