Storage disk replacement - database considerations

[cookiemonster]

Hi.
I had to give up trying to setup motion detection a long time ago. I've been mocord since. I have two cameras mocording on a smallish 2 TB GB drive that gives me only 5 days for the events.
I am awaiting delivery of a new drive. I am OK with losing all events when I replace the disk.
The question is about the zm database and the audit process. I want to avoid both leaving the database in an inconsistent state that forces the audit to spike for a long time until the inconsistencies have been dealt with.

Recreate the database objects? Seems too heavy-handed. I know I can "delete * from events;" but I don't know the db structure so there might be some foreign key constraints on other tables that need taking care of.

So what do people do? What is the recommended approach?
Edit: corrected disk size.

[Andyrh]

Can you add a disk? If so just point new events at the new disk and wait five days or move the events.
5 days of events should not cause audit to run a long time. How many events is 5 days? In my case 7 days is ~20k events and I have lost all 60 days to a bad RAID controller. Audit cleaned it up in a few hours and did not cause new events to be lost.

I have found ZM to be robust in surviving HDD problems.

[cookiemonster]

thank you for the input. I have just shy of 1600 events in total. Each is about 1.2 GB in size.
I haven't looked yet if I can add the disk but it's possible that I can't and have to replace. Number of SATA ports depending.
However what I want to avoid is the cpu spike. No need to burn electricity if it can be avoided, and it occurs to me that it can. But sure it will only be a few hours I expect but maybe about 2-4.

[cookiemonster]

The new disk has arrived and the long SMART test will finish tomorrow, when I hope to install it for Zoneminder.
Any other thoughts anyone? Just yank old, put new one in and let audit repair the database? Anything better?

[bbunge]

Would be best to add the new drive to the computer then set up ZM to use it leaving the old drive in place. Set a filter to delete the events on the old drive, 100 at a time and when the old drive is empty remove it from ZM, remove the mount from Linux and take the drive out of the computer.

[dougmccrary]

I'm a little bothered by you running zmaudit - it sounds like you may have an underlying problem, or why are you running it?

viewtopic.php?p=115118&hilit=zmaudit+on+1.36#p115118

[Andyrh]

I am not sure why you are bothered. I ran an audit when I lost a file system. In this case the OP may plan on loosing a file system with the HDD change. There is not an underlying problem, just a plan to clean the DB. The OP is asking for the best way to change HDDs.

dougmccrary, I think you may have misunderstood the context of the question.

[dougmccrary]

dougmccrary, I think you may have misunderstood the context of the question.

Might be. But as bbunge and then you said, if hardware possible, just add the new drive and wait (or not) and filter.
So why even worry about the DB, which is on the system drive (most likely)?