Doubts about openmediavault-plugin ddfull for microsd

1. offizieller Beitrag

    Hi,


    was reading this thread [Backup Plugin] create a single img backup image for use with win32 disk imager / etcher, etc.


    So if i understand this correctly, i can install the openmediavault-backup plugin and:


    -backup full microsd card.

    -write the resulting image to a microsd card to restore.


    Got it right?


    I'm actually powering down my Odroid HC2, removing the microsd and cloning it with usbimager.


    Would like to ask how the plugin works, or better saying, how backing up a running system works in this case? Should i stop some services before starting the backup process?


    Thanks in advance!

    • Offizieller Beitrag
    Zitat von steakhutzeee

    Got it right?

    That's the idea.


    Zitat von steakhutzeee

    I'm actually powering down my Odroid HC2, removing the microsd and cloning it with usbimager.

    This is a better backup since nothing is running.


    Zitat von steakhutzeee

    Would like to ask how the plugin works, or better saying, how backing up a running system works in this case?

    It runs a command against the system. If the data changes while the image is being written, then it will be wrong when restored. Most of the time (databases like mysql excluded), it won't cause a problem.


    Zitat von steakhutzeee

    Should i stop some services before starting the backup process?

    That is better but may not be a problem depending on what is running on your system.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Gefällt mir 1
    Zitat von ryecoaaron

    It runs a command against the system. If the data changes while the image is being written, then it will be wrong when restored. Most of the time (databases like mysql excluded), it won't cause a problem.

    Interesting, could you elaborate more?

    Or better, maybe i can do some kind of check before starting a backup of this kind?

    • Offizieller Beitrag
    Zitat von steakhutzeee

    could you elaborate more?

    If you choose ddfull, the plugin runs a dd command that will read the blocks of the os drive sequentially and write them to a file. If one of those blocks changes after it has been read and written to the image file, it could cause an issue.


    Zitat von steakhutzeee

    maybe i can do some kind of check before starting a backup of this kind?

    Sure. Test backing up your system and restoring it multiple times.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Zitat von ryecoaaron

    If you choose ddfull, the plugin runs a dd command that will read the blocks of the os drive sequentially and write them to a file. If one of those blocks changes after it has been read and written to the image file, it could cause an issue.

    So this could happen:


    dd reads a block, the block change in the meantime, the read value is written - but the block changed in the middle so it's wrong, Correct


    Well powering down and clone the microsd sounds a lot safer. Assumed that the user should always test the backups, the ddfull seems a risk.

    • Offizieller Beitrag
    Zitat von steakhutzeee

    Assumed that the user should always test the backups, the ddfull seems a risk.

    For the average home user, you would never notice. This is also why I prefer copying at the file level. Your backup may have older files but not partially changed blocks.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag
    Zitat von steakhutzeee

    So you say it's better to shut down and clone right?

    It is better to shutdown. But what I am trying to say is you keep backing up your system by shutting it down say once a month but use the online backup daily, I think you can get the best of both worlds.

    Zitat von ryecoaaron

    It is better to shutdown. But what I am trying to say is you keep backing up your system by shutting it down say once a month but use the online backup daily, I think you can get the best of both worlds.

    So in case of disaster the first restore should be from the ddfull and in case it does not work as intended i can use the backup performed shutting down?

    • Offizieller Beitrag
    Zitat von steakhutzeee

    So in case of disaster the first restore should be from the ddfull and in case it does not work as intended i can use the backup performed shutting down?

    That is what I would do.

    • Offizieller Beitrag
    Zitat von steakhutzeee

    Maybe this is dumb but i'll try, say i restore and it seems to be working. There is some way to check the system integrity. Just to be sure that issues that could happen after some time are not related to the restore.

    That would be tough because there may be a changed block in a log file or some other non-package file. There is no checksum to know that this is different but it also doesn't cause any problem. I think in 99% of cases, you will know quickly. If your system is too important to risk this, then you will have to keep doing the offline backup. My systems can be recreated easily because there is no data on the OS drive. So, other than an inconvenience and time to recreate, an OS drive failure isn't hard to recover from.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    ddfull gives you an image you can just write to the media. dd requires you recreating grub (on some systems), mbr, etc, and then write the partition image. So, ddfull is just easier. I kept the dd option because some people have extra data partitions that might be very large that they don't want in the OS backup.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Zitat von ryecoaaron

    ddfull gives you an image you can just write to the media. dd requires you recreating grub (on some systems), mbr, etc, and then write the partition image. So, ddfull is just easier. I kept the dd option because some people have extra data partitions that might be very large that they don't want in the OS backup.

    Thanks a lot!


    So my first backup took 40 minutes. All 32 GB were read and the dd full backup image is less than 2 GB. The microsd is 32 GB. Cloning it after shutdown only took 8 minutes. It's because it's live?


    Two other things:


    -It's ok to manually delete the backup files i assume.

    -i can just copy somewhere else the .ddfull.gz file ignoring the other files generated by the backup process? If yes, why they are needed also after the backup is complete?

    • Offizieller Beitrag
    Zitat von steakhutzeee

    It's because it's live?

    Probably. The OS is using the OS disk which will make any backup slower.

    Zitat von steakhutzeee

    It's ok to manually delete the backup files i assume.

    If you want. That functionality is builtin to the backup plugin if you scheduled it. That is what the days to keep is for.


    Zitat von steakhutzeee

    i can just copy somewhere else the .ddfull.gz file ignoring the other files generated by the backup process?

    I assume you mean a different server? Yes.


    Zitat von steakhutzeee

    If yes, why they are needed also after the backup is complete?

    They aren't needed for ddfull. They are just helpful files to have for advanced users.

  • steakhutzeee

    Hat das Label gelöst hinzugefügt.

    I would like to store my backups on the cloud with Duplicacy. In order to deduplicate the backups I should upload the files uncompressed. If I uncompress the .ddfull.gz what is the best way to compress the file again manually later?

  • steakhutzeee

    Hat das Label gelöst entfernt.
    • Offizieller Beitrag
    Zitat von steakhutzeee

    I would like to store my backups on the cloud with Duplicacy. In order to deduplicate the backups I should upload the files uncompressed. If I uncompress the .ddfull.gz what is the best way to compress the file again manually later?

    You really shouldn't. If you do, duplicati will want to upload those files because they are "new".

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden