Open for Voting

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

FormerIdeaCreator
Parents

  • 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.

Comment

  • 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.

Children
No Data

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification Media Vault Link Accounts
About THWACK Blogs For Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2024 SolarWinds Worldwide, LLC. All Rights Reserved.