柒火
你說的這種外包程序員應該不是正規外包公司的，而是那種小作坊或者野路子程序員。
第一件事就是保留現場（代碼和日誌等），然後請專業的程序員review代碼，提取和保留證據。然後報警。
一般外包的程序員水平都比較差，不可能不留下痕跡的，後門都有套路可以尋找，稍微懂行一點的程序員都很容易找到後門所在。
對待沒有職業道德的外包人員，一定不能手軟。
互聯網活化石
1、保留現場：馬上把服務器物理切斷聯網(最簡單是撥網線)，不對服務器作任何操作(就是啥也別動)。
2、報警
以我對it行業的瞭解，如果真有人敢用“刪數據“這樣惡劣的手段破壞，跟假疫苗害人子孫差不多了。
但是也不必過於擔心，通常程序員對於數據備份是一種天然本能，對方極有可能做好了備份再刪除的，這是一種習慣，剩下的就是如果讓對方交出來了。
假如真沒備份，也可以請數據恢復公司進行恢復，只是價格比較昂貴，但大多數都能恢復的，時間越短成功率越越高。
還有一點，無論對方用何種方法刪除數據，都會留下蛛絲馬跡，警方會有專業人員或委託第三方專業機構對服務器中的數據、文件、可執行程序、數據庫可執行事務，過程等等分析，試圖查出數據被刪除的原因，理論上是不可能查不出原因的。
等於五
看你就是個菜鳥 ，誰讓你只准備一套服務器？活該………
你要有兩套源碼，一套做備份，一套上線。
備份那套可以在項目交接後，給第三方機構，做後門檢測，一般費用就幾千塊。如果發現惡意代碼，可以起訴，並且要求賠償。
另外你肯定有欠款，以我多年開發的經驗。你沒有欠款？我把我的特斯拉都吃了。
為啥有欠款？我估計因為資方要改需求引起的，作為勞方最不能忍受的就是改需求，這肯定要二次報價的，而資方卻認為改這麼點東西又要收錢？於是矛盾就來了，歸根到底，資方自己對自己的項目都模糊不清，想當然，你這種人就看太多了。
還記得前一段時間新聞那個白痴的產品經理嗎？居然要求程序員去開發一個APP，可以根據手機外殼而改變顏色，碼農不揍死你才怪，同一個公司尚且如此，外包就更加不用談了。
解開世界公式魔王
首先說下外包，因為以前我就在類似公司待過，大多數外包公司都有個心理，就是實在不行就只拿首款，尾款能不能拿到無所謂。其實可以發現從一開始就根本是沒法結項的。
說個案例：
甲方外包給乙，100萬項目款同時要求得有後臺、前端、移動端App。
乙公司只有後臺研發人員，那怎辦放棄另外兩個嗎？顯然不會，100萬必須全部拿下！
接下來，把前端20萬二次外包給丙，同樣移動端20萬給丁，但是各抽成10萬。
丙丁兩家公司每人只有10萬塊錢，那做的東西無非就是應付下。
現在明白了嗎？中間所有人都只想著怎麼賺錢，最後倒黴的卻是甲方，發現項目效果達不到預期，要求乙修改對應內容再結尾款，而丙丁要求乙先結尾款再改，如此惡性循環。
AAENIUNE
被刪庫了怎麼辦？
1、首先嚐試找回數據，扯皮的事情後面再說。
數據庫被破壞的程度，取決於外包恨你的深度。不同的破壞程度有不同的修復方法。如果是邏輯刪除，比如刪除了某些重要數據或者某幾張表，可以通過閃回查詢或者回收站找到被刪除的數據；如果是物理刪除，比如刪除表空間或者直接格式化磁盤，那就必須通過備份恢復數據庫。這裡面的情況比較複雜，簡單點說就是：題主必須儘早找一個懂數據庫的人檢查數據是否能恢復，能恢復到什麼程度？
2、如果技術角度無法恢復數據，那就準備談判吧
外包故意刪除甲方的數據庫，不外乎兩個原因。第一，要挾甲方，催回款或者續保；第二，已經和甲方撕破臉，回款不要了，以後相忘於江湖。外包的老闆如果夠成熟，一般都不會徹底撕破臉皮，刪庫只是手段，拿到錢才是目的。他們在刪庫前肯定會備份數據，或者只是改一下表名。這種情況下，題主應該找領導和外包老闆深入交流，達成某些共識，然後外包的工程師會告訴你他們用只可意會不可言傳的方法找回了數據。
3、如果談判破裂，那就準備追責吧。
如果談判沒有效果，那就要通過法律來解決了。從問題看，題主最關心的還是要追究外包方的責任。要從兩個角度下手。第一，合同。強勢的甲方都會設計對己方有利的合同，一般合同期和質保期內，只要出問題，乙方都要負責解決。第二，問題定位。通過技術手段定位故障源是外包開發的應用或者外包的終端。說實話，這方面我不怎麼抱希望，從題主的問題可以看出，題主的單位應該沒有采取有效的審計手段。那隻能從監聽日誌和解析歸檔日誌著手了，過程相當複雜，建議找個好的數據庫工程師。
4、如果以上都沒有效果，那就只能重建數據庫了
如果任何手段都試過，實在拿外包公司沒有辦法，那就只能自己痛苦地重建數據庫了。向外包公司要數據字典（對方有這個義務），收集原始數據，手工錄入新建的數據庫。如果業務流程都有紙質工單保留，可以發揮人多力量大、愚公移山的精神在應用端重新錄入業務流程；如果沒有保留紙質工單，那就到此為止了，後續數據丟失造成的損失需要通過行政來解決。
太讀
先想想為啥刪庫呢？最大情況無非就是你沒有給別人尾款甚至從未支付過任何費用。
甲乙方合作的基礎很簡單，甲方付錢，乙方收錢做開發。
甲方給多少錢，乙方做多少事，別老想著小兩千就要求做出淘寶，要不甲方自己做唄還一分錢不花。乙方需要嚴格按照難易度和工期敲定價格，才會規避甲方的各種不合理要求難以收到尾款。
良好的溝通才是雙贏的保證。
陽光友華
不用說，肯定是你沒給夠錢。
說實話，這種事你連工錢都給不起，報警都沒用。不是黑客入侵就不是刑事犯罪，立不了案。民事糾紛打官司，講證據，你有什麼證據證明是程序員刪的？系統自動刪的，什麼條件會觸發？程序員只要說是個bug你一點轍沒有。
所以請人外包事先訂好需求，籤合同，按合同執行。讓人做事還不給夠錢，程序員有很多辦法讓你之前花的都打水漂，善待技術人員！
自由踐行
給您提供建議如下：
（1）如果是測試環境，影響較小
如果是測試環境，影響較小，刪除數據庫的事情可以通過重建測試數據庫重建。然後如果確認是外包程序員做的，可以通過公司對外包公司施壓，要求以後加強管理，畢竟是甲方和乙方的關係。
（2）有可能是病毒程度？
如果是網上下載的數據庫連接工具，如pl/sql developer，有可能被植入了病毒程序。如之前遇到過的勒索病毒，刪數據病毒等。這樣就要加強軟件的管理，不允許使用互聯網下載的非正版程序，以免間接引入病毒。
（3）是否有數據庫審計，堡壘機等
通過技術手段，能否對登陸用戶的行為進行審計、判斷和分析，由此來找到具體的操作命令是什麼，什麼用戶操作的，通過哪臺PC機連入數據庫操作的，通過這些線索大概判斷是誰操作的。
（4）如果是生產環境，先恢復數據
通過您的描述，只是數據庫被刪除。如果生產環境管理規範，一般會有定期的邏輯備份、RMAN備份、異地備份等，通過這些數據，先重新安裝數據庫，然後恢復到最近的數據狀態，將損失降到最低。
（5）責任是否清晰，問題定責
如果是生產環境，或者比較重要的其他數據庫。那麼數據庫的運維工作是否外包，工作的職責是否也該由外包公司承擔？如果能明確責任，那麼就可以按照規章制度以及合同要求，進行問題的定責了。
（6）責任不清晰，終極方案
如果責任不能明確，但又確實造成了損失。當務之急就是讓生產/測試環境恢復正常，力所能及的通過可行的技術方案（比如直接讀硬盤恢復數據等強力技術手段），讓業務先恢復正常，降低事故造成的影響。商務上面的事情，上報領導，由領導出面與對方公司協商處理。
希望對您有幫助，謝謝！
話入神機
如果嚴重造成了公司的經濟損失，那就報警；什麼事情都要自己溝通解決，還要警察做什麼。
當然，在報警前，一些必要的事情還是要做的，說不定可以降低已有的損失。
先反思自己
至少我還沒見過估計給程序留後門，刪除客戶數據的乙方；但是我見過很多拖著尾款不給的客戶。
發生這樣的事情，先反思一下自己對乙方是否有以下行為：項目開發過程中增加很多額外的需求，但是沒有增加費用；項目驗收過程中，是否“雞蛋裡挑骨頭”，扣除了開發費用；項目已經交付，故意拖著尾款不給；
如果有的話，那麼先和外包公司溝通，該給的錢給了，然後讓對方看看數據能否恢復。
開始溝通千萬別說“就是你們刪的，快給我弄好”，是誰也不會承認的。
可以先禮後兵：“（裝作什麼都不明白）不知道什麼問題，數據都沒了，你們比較專業，幫忙看看有沒有辦法恢復，我們可以加一些費用”。
恢復數據
比找外包理論之前，還有更重要的事兒，就是想辦法恢復數據了。
一些公司，數據庫都會設置設置成主從模式，這種情況的話是好辦的，不過大部分公司，還是單臺數據庫運行。
如果是單臺數據庫的話，也是有可能找回數據庫的，例如MySQL，可以使用數據庫備份+binlog日誌的方式恢復數據庫：時間起點=最近一次備份數據庫的時間，時間終點=DROP操作前的一個操作，然後將binlog中的操作重新執行一遍。
如果數據沒找回來，並且造成嚴重經濟損失的話，那麼該報警就報警吧，下一次，記得對外包好一些。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
一，釐清責任，是外包的問題還是你們內部本身管理的問題。不是說外包刪的，運維團隊就沒有責任的，這要看你們運維團隊的構成和運作形式。
二，保留現場，責任釐清之前不要做任何操作。因為這可能導致二次傷害，而只要你操作並造成二次傷害了，則責任百分百在你！如果你操作成功恢復了，則責任不一定就在外包，這點請深刻體會！
三，責任明確後，保留現場的情況下做損壞評估，切記先有預案再動手，不要盲目的嘗試。如果有條件儘量通過dd或者快照的方式，再造一個現場環境出來進行測試。
四，最後才是追究責任，法律程序和賠償問題是最後才進行討論的。
五，數據無價！有些數據一旦丟失仔也找不回來，尤其是關係型數據！重要的生產環境不要讓非運維人員輕易用高權限帳戶進行操作！
六，通過這次事件提高安全等級，要預算，要編制，把壞事轉化成教訓，以期在將來運維上能有實質性進步，從而成為一件好事！
七，運維有風險，一次就足夠葬送職業生涯，要保守謹慎，不要把開發思維帶到運維上，千萬要警惕那些開發轉運維的人員！！儘量使用專業的運維人員。
