Open for Voting
over 2 years ago

Undeleting an element (node/interface/volume etc.)

A few minutes ago I accidentally deleted my backbone switch (and all the interfaces of course). Since undeleting an element (node, interface etc.) is not possible (Except restoring SQL from backup) it means that I've lost all the interface statistics, node statistics (CPU, Memory, Availability) and atlas map drawing. And this is not my first time. This is a common issue for all of us. If NPM can remember an element for a specific period of time that would be great. I think It shouldn't be that hard to implement this.

PS; Please vote these ideas also if you like them of course. And I bet you do. emoticons_happy.png

  • I'm guilty of doing this a handful of times with applications or other node inventory, although my most egregious  mistakes have been making direct updates. Thank the maker for database backups for those small, easy to recover hickups. Losing all your history is another story altogether. It would be great if deletes were maybe processed during nightly maintenance so you had some time to recover it if you deleted it by mistake.

  • Yes, it works okay on 12.2 -- though the trigger got moved to NodesData as Nodes is now a view.

  • Bump/Agree. I once managed to accidentally delete a top-level supernet from the IPAM; which of course deleted the MANY subnets below this.

    That was a major nause. I luckily had an exported excel file which contained most of it and used that to partially restore.

    A recycle-bin feature would have saved the day in the case of my error.

    Plus-plus on this feature-request.

  • I don't  know if I have deleted anything because it is not there to see/know!
    Considering the need for compliance with regulatory and corporate requirement that data be retained for a minimum period we would benefit from the knowledge that "deleted" items are still recorded but in muted mode.

    I propose that SW consider NOT DELETING the data but changing the status to "Deleted"

    There could be two levels/steps of "Delete" ;

         1. change the status to deleted (mute the item/s including dependants and set the status to "Deleted"

         2. remove the item with a status of deleted. The items, along with dependants are deleted from the database.

    This way when we look for -  old relationships, configurations etc. they are still there..

    If we want to remove a Node or related element created in error the second step confirms the activity.

    A "Deleted" status would provide historical knowledge and assist with configuring a new replica Node and or its dependant items.

    I believe this would be easier to implement than a recycled recycle bin.

    ASLO the ability to "script out" a configuration would also provide configuration but a network discovery will rebuild that I suppose.