If SD card is defect......what to do?

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • If SD card is defect......what to do?


      what is the best solution if Micro d (on i.e. Odroid) is defect? I'm asking because want to have a solution before shit happens... :D

      Some wrote to have always some clones in backup. But what does it mean if the System did grow after making the clone? Should I always make a Clon as soon as I put data on the HDD?

      Or should I install an new OMV on a new Micro SD Card. But I'm not sure if and how the HDD with all These data can be used without formatting...

      Any idea/hint?


    • For a phone:
      If your card fails, when you pop in the clone, you'll have what was on your original SD-card as of the last clone. If the clone was done 2 weeks ago, the last text message you'll have would be two weeks old, but having a 2 week old cloned card is far better than losing everything. (The text thing is an example - I don't know exactly what is stored on a smart phone SD-card.)

      Cloning SD-cards is a very good idea because the media is not known for being ultra-reliable. The best way to head off problems before they start is to buy a name brand SD-card (no generics), and test the new blank card with h2testw1.4 to see if it's error free and the correct size (there are cheap fakes out there).

      If you're flashing OMV onto an SD-card, using Etcher (recommended), pre-formatting the card is not required. And, yes, it's a good idea to have a clone of your OMV installation. If you make significant changes to OMV or have downloaded new updates, I'd wait a week or 2 to verify that all is working fine, then update the clone.

      Edit: If h2testw1.4 detects errors on an SD-card, nothing can be done for it. Throw it away.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 1 time, last by flmaxey: edit ().

    • flmaxey wrote:

      pre-formatting the card is not required
      While this is true today I would always recommend to do a 'Quick Format' with SD Association's 'SD Formatter' (available only for Windows and macOS unfortunately).

      This tool does the following:
      1. Full TRIM over the entire SD card capacity
      2. Applying a partition table and a filesystem so the card is afterwards either formatted as FAT or exFAT (depending on size/standard -- all cards larger than and including 32GB are AFAIK ExFAT)
      As @flmaxey said pre-formatting is useless so 2) is of no use here. But we really want 1) for three reasons:
      • A full TRIM on mediocre or crappy SD cards restores performance back to 'factory settings'. Those cards once there has been written more data to than their native capacity get slower. A full TRIM will fix this.
      • The card now operates more efficiently and wears out later since the card controller knows now which pages of the flash media are empty and can exclude them from wear leveling and garbage collection. Doing such a full TRIM from time to time is always a great idea.
      • Since the TRIM marks all pages on the SD card as empty when reading now from the card at the block device layer everything will be returned as zeroes. This is a huge advantage if you do not clone your cards afterwards but create compressed device images with whatever tool.
      To elaborate on the last part: if you reflash an image to SD card without a TRIM in between all already used pages will NOT be overwritten. Say you have a 16 GB SD card and 4 GB on this card had been written to. If you now burn a new image on this card that is 1 GB in size then the following happens:

      If you look at the card at the filesystem layer 1 GB is used only (less used). If you sync the card's contents now with eg. rsync only 1 GB will be copied. When you do a clone of the card at the block device layer the whole 16 GB will be copied and 5 GB (4 + 1) contain data. Such data does not compress that great compared to only zeroes. So with a clone of such a 16GB card with applied compression and a notional 1:2 compression ratio for the 'used data' we end up both times with an image of 16 GB size uncompressed. But the compressed size of the non-trimmed image will be 2.5 GB (5 GB / 2) vs. 500 MB (1 GB / 2). Since 'only zeroes' do compress very well.

      So please do yourself a favour and always follow these steps:
      • Always test your SD card with either F3 or H2testw first to check for counterfeit/broken cards. Always directly after purchase
      • Then use SD Formatter to perform a full device TRIM
      • For satisfying results burn our images only with Etcher (no need to decompress, Etcher will verify the burning process and saves you from some common SD card troubles)
      With USB thumb drives it's basically the same but unfortunately we usually can't make any use of TRIM here so in fact SD cards are the better option compared to USB pendrives. No need to use old and crappy cards. Today insanely fast SD cards compliant to 'A1 app performance class' are avaible. Well, this is even the 1st step: buy a good SD card and not rely on some smelly old card you found in the drawer...

      Well, I didn't address the original question how to clone but just tried to explain the ideal prerequisits that make cloning to compressed device images more easy and that help your SD card living longer.

      Advanced stuff (please skip if already confused by the above):

      My personal take on cloning cards is somewhat special since I have a dedicated SBC for this where a script does the whole job. Cards are read with ddrescue, then I let the script empty caches and compare md5 hashes of block device and image (verify), then the image will be copied to the final destination which is a zlib compressed btrfs. A snapshot is created prior to the copy and the already existing device backup will then be overwritten. With this approach I get all the compression goodness and new device backups only take up the space needed for an incremental update (only changed blocks are now part of the next created snapshot).

      This way the filesystem does the compression job (multithreaded) and also storing just the differences to the last clone. If the SD card dies (ddrescue + md5 verify will tell me unlike dd or WinDiskImager and other tools that blindly believe into they copied correctly) I take the image from latest snapshot and then write it to a new card. Helps keeping write cycles low compared to permanent 'card to card' cloning.

      The post was edited 2 times, last by tkaiser ().