Some of the UniFi UNVR’s have system files on a USB drive. There seem to be a number of the drives failing recently, rendering the UNVR inoperable. Fortunately it is easy to replace. The following steps should preserve the video recordings.
Steps to recover UNVR
- Power off the UNVR
- Remove the USB drive (use a heat gun or screw driver to break the glue that is holding the USB drive)
- Install new USB drive
- Temporarily remove UNVR HDDs (this may not be necessary, but rather be safe then sorry.)
- Boot UNVR with new USB drive. (Give it a little time to format and copy contents to the new USB drive. Should not take more then 30 minutes.)
- Setup the UNVR like it was before
- Power off the UNVR again
- Reinstall the HDD’s
- Power on the UNVR
- Log in and reconfigure the users
Note on Recovery
You could potentially mount the failed or failing USB drive on a Linux machine copy off a UniFi backup. Unfortunately, the UniFi Protect backup does not preserve the users. Just the video groups. You will probably have to resend invites to users.
Note on the video storage drives
It sounds like the UniFi Protect system will try to read the drives and if it can preserve the data or read the raid information it will try to use that. That is what it sounds like at least from the forums. More info on drive management.
List snapper BTRFS snapshots with
If you are in recovery mode on Fedora, add –no-dbus right after the snapper command. e.g.
snapper --no-dbus list
You can use the diff command to list the changes that happened between snapshots.
snapper --no-dbus diff 108..109
And to undo a change or all the changes between a snapshot, do the following. Where 108..109 are all the changes you want to remove. So essentially going back to snapshot 108.
snapper --no-dbus -v undochange 108..109
Error code: 0x000000f
The Boot Configuration data for your PC is missing or contains errors.
The following notes may be of some help when trying to resolve the above error. Think the primary issue had to do with cloning a GPT drive to a RAID array that was using MBR. So think everything worked after converting it to GPT
All the commands are/were run from a recovery Command Prompt
Convert MBR disk to GPT
After running the following command the EFI directory was automatically created.
The command is supposed to be non destructive. Change the disk to whichever disk your trying to change to gpt.
gpt2efi /validate /disk:0
If running the above command did not work then you may give the following command a try. Change the drive names where appropriate.
bcdboot c:\windows /s s: /f UEFI /v
You may be able to get away with just using
You can check if the above worked by seeing if it created any files in the directory, if new efi partition is S:, then from a command prompt run
Commands for recreating the EFI partition (WARNING! MAY DESTROY DATA!)
select disk # Note: Select the disk where you deleted the EFI System partition.
create partition efi
format quick fs=fat32
sudo port install ddrescue
If you don’t have ports installed, then I would recommend doing some web searching on how to install ddrescue.
identify the “name” of the disk you want to “image” .
Macbook:~ bob$ diskutil list
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *200.1 GB disk0
1: EFI EFI 204.2 MB disk0s1
2: Apple_HFS Mac 199.7 GB disk0s2
3: Apple_Boot Recovery HD 641.1 MB disk0s3
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *250.8 GB disk1
1: Windows_NTFS Windows Hard Drive 250.8 GB disk1s1
The first disk “disk0” is the OS X System disk, the second one “disk1” is an external drive, the one I want to image.
Change /dev/disk1s1 to your disk. If you have multiple partitions and want to image the whole drive then just use the disk name like “/dev/disk1” instead of “/dev/disk1s1”.
sudo ddrescue -v /dev/disk1s1 ~/Desktop/ddrescue.dmg ddrescue.log
In the above command I am attempting to rescue data from the first partition on disk1 and send it to an image “ddrescue.dmg” on my desktop.
Now go get some coffee, lunch, etc. and it might be finished when you get back…