首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lovefc
V2EX  ›  公司运营

centos 炸掉了，急求解决办法

  •   
  •   lovefc · 2018-12-21 09:41:16 +08:00 · 7823 次点击
    这是一个创建于 2172 天前的主题，其中的信息可能已经有所发展或是发生改变。

    原因是这样的，是一个 vm 上安装的 centos 系统，然后我发现 home 分区不够用了，就从 root 分区里分出 10g 加到了 home，命令提示是正确的，但是 df -h 之后并没有添加上，然后我就重启了，重启后就 gg 了，提示如下图所示的错误。 错误

    然后我去百度这个错误，参考了

    通过 grub 修改 kernel 参数，在 kernel 那行中加入 selinux=0，或者是 enforcing=0,然后点击 Enter 键，再点击 B 键

    然而都没有作用，求大神帮我看看怎么肥事，可偿！

    第 1 条附言  ·  2018-12-21 10:51:46 +08:00
    我所使用的命令是百度到的命令,具体如下

    先吧 / 里面 50G 分 10G 出来

    lvresize -L -10G /dev/mapper/vg_srv1459-lv_root

    然后把这 10G+到 /home 里面

    lvresize -L +10G /dev/mapper/vg_srv1459-lv_home

    然后投入使用不音响你现在的文件
    resize2fs /dev/mapper/vg_srv1459-lv_home
  • centos
  • kernel
  • 错误
  • 分区
    51 条回复  •  2018-12-27 16:00:16 +08:00
    lovefc
        1
    lovefc  
    OP
       2018-12-21 09:41:59 +08:00
    顶帖，让大家看到，现在慌的一匹，烟都拿不稳了，因为这台服务器上有东西在使用
    lovefc
        2
    lovefc  
    OP
       2018-12-21 09:44:26 +08:00
    大佬快点出现啊
    alvin666
        3
    alvin666  
       2018-12-21 09:45:09 +08:00 via Android
    关注一下（ lz 居然还敢减分区大小...）
    挂个 live 能进去把文件拷出来吗，or 备份？
    lovefc
        4
    lovefc  
    OP
       2018-12-21 09:47:11 +08:00
    @alvin666 大佬能说详细些吗？怎么备份？我这方面小白，你说的太简略了
    oott123
        5
    oott123  
       2018-12-21 09:50:11 +08:00 via Android
    你至少需要说明：

    1. 原来的分区表是什么样的？
    2. 你使用了什么命令什么方法操作了分区？
    alvin666
        6
    alvin666  
       2018-12-21 09:50:15 +08:00 via Android
    @lovefc 第一，重要的东西定时备份，现在没备份就只能救
    第二，挂载一个 Linux live 的镜像进去，再挂载虚拟机的目录，看看能不能把文件拷出来
    第三，都 8012 年了还有人敢调分区不备份，竟然还敢缩分区...（建议了解一下 ext4 的文件分布）
    Bardon
        7
    Bardon  
       2018-12-21 09:50:52 +08:00
    重新开一个 vm，将这个坏的挂载上，fsck 跑一遍。
    这么小白，公司怎么让你接触 centos 的。
    alvin666
        8
    alvin666  
       2018-12-21 09:53:38 +08:00 via Android
    @Bardon fsck 可能会把根目录的一些文件直接弄没了，我觉得应该把 home 分区放弃掉，按照相同柱面号把 root 分区重建上，这样 root 分区的文件就全回来了
    lovefc
        9
    lovefc  
    OP
       2018-12-21 10:01:06 +08:00
    @alvin666
    @Bardon
    @oott123

    大佬们，看你们的回复，我心都凉了，我现在是毫无办法了，我也不是做运营的，只是个复制粘贴的 php 程序员，硬着头皮上的，救救我
    liwl
        10
    liwl  
       2018-12-21 10:01:22 +08:00
    且在江湖中，不说一个狂字。
    尚未丰翼前，怎敢一飞冲天。
    zcl0621
        11
    zcl0621  
       2018-12-21 10:01:32 +08:00
    用 livecd 看下磁盘分区 首先看能不能挂载 root 分区 能挂载就尽快备份数据 备份完数据后 尝试修复文件系统
    lovefc
        12
    lovefc  
    OP
       2018-12-21 10:04:35 +08:00
    @zcl0621 具体如何操作？你把我看成纯小白即可，大佬，你说话我听不懂啊
    alvin666
        13
    alvin666  
       2018-12-21 10:04:53 +08:00 via Android
    @zcl0621
    @lovefc
    两个分区至少能救一个，你这种缩分区直接挂载会随机丢文件，fsck 之后那些文件就直接没了，所以应该还是删除一个分区，把另一个扩充，再挂载
    RoyL
        14
    RoyL  
       2018-12-21 10:05:19 +08:00
    惊了,不备份你就敢上,真删库到跑路
    lfzyx
        15
    lfzyx  
       2018-12-21 10:05:20 +08:00
    所以还是早点换 debian 吧
    zcl0621
        16
    zcl0621  
       2018-12-21 10:06:36 +08:00
    希望你缩容的那部分磁盘没有涉及到 inode 数据。。。 只有 block 数据
    lovefc
        17
    lovefc  
    OP
       2018-12-21 10:07:17 +08:00
    @zcl0621 我刚刚百度了下，镜像，U 盘启动，关键是我离机器很远，是远程操作的
    sunnyadamm
        18
    sunnyadamm  
       2018-12-21 10:08:15 +08:00
    减分区，，，这波操作真的骚
    zcl0621
        19
    zcl0621  
       2018-12-21 10:09:42 +08:00
    服务器么？一般有管理口的呀? 通过管理口访问呀
    话说 这个时候就要找你们的运维(专业背锅侠)同事啦
    orqzsf1
        20
    orqzsf1  
       2018-12-21 10:11:38 +08:00
    递支🚬请教下公司的运维老师傅吧
    cxh116
        21
    cxh116  
       2018-12-21 10:11:45 +08:00
    看你这回复,如果数据重要,推荐你马上把机器关了,不要动机器了,找专业人士帮忙处理,不然数据真的连恢复都没有可能了.
    zcl0621
        22
    zcl0621  
       2018-12-21 10:13:38 +08:00
    如果数据很重要,直接联系数据恢复公司,自己不要再处理了,如果服务器还是磁盘阵列的话,修复难度非常大
    找找看数据恢复公司
    harker
        23
    harker  
       2018-12-21 10:14:05 +08:00
    远程操作那就更麻烦了，祝你好运
    liwl
        24
    liwl  
       2018-12-21 10:18:57 +08:00
    看错误提示，是虚拟卷，本来就可以动态扩容啊。保重。物理机还是？
    Ansen
        25
    Ansen  
       2018-12-21 10:21:17 +08:00
    看报错，用的是 lvm，如果命令正确的话，数据应该问题不大，试试拿 livecd 救一下（记得先备份数据再尝试修复）
    lovefc
        26
    lovefc  
    OP
       2018-12-21 10:33:17 +08:00
    @orqzsf1 这个公司没有运维，运维就是我这个半吊子

    @liwl 关键是从未做过
    reus
        27
    reus  
       2018-12-21 10:39:34 +08:00
    你一不说配置，二不说操作过的命令，谁帮得了你？

    不用想了，没救的了，该赔赔，该炒炒，负起责任来。
    reus
        28
    reus  
       2018-12-21 10:46:01 +08:00
    绝大部分文件系统在缩容的时候是需要 umount 的，而根分区不可能 umount，所以命令极有可能是不对的。

    而且还涉及 lvm，正确的步骤是：
    用 live cd 启动，根文件系统缩容
    根 lv 缩容，这一步要极度小心，不可以缩得比文件系统小
    home lv 扩容
    home 文件系统扩容

    如果你不是按照这个步骤做的，那就没救。
    lovefc
        29
    lovefc  
    OP
       2018-12-21 10:55:11 +08:00
    @reus 我更新了我的命令
    reus
        30
    reus  
       2018-12-21 11:00:59 +08:00
    @lovefc 那根文件系统就没救了，文件系统都没缩容你缩什么 lv 啊…… 自己不懂原理，不知道命令有啥用，又不知道自己的操作有多危险，你怎么敢执行这些命令？

    home 目录应该没问题。
    liwl
        31
    liwl  
       2018-12-21 11:05:28 +08:00
    @lovefc 保重，没救了
    vipdog73
        32
    vipdog73  
       2018-12-21 11:15:40 +08:00
    没弄过这种问题，没经验啊
    P0P
        33
    P0P  
       2018-12-21 11:19:26 +08:00
    在造成更大损失之前，尽快联系数据恢复公司吧。另外楼主是在 vm 跑的 centos，看一下 vm 的硬盘文件有没有自动备份吧
    defunct9
        34
    defunct9  
       2018-12-21 11:44:22 +08:00   ❤️ 5
    开 ssh，让我上去看看
    gamexg
        35
    gamexg  
       2018-12-21 11:45:42 +08:00
    看操作，
    root 分区挂了，home 没问题。
    个人应该无法恢复，找专业数据恢复公司吧。
    千万别再执行任何操作了，立刻关机！！！

    额，虚拟机？
    立刻做快照，保留当前状态，再找数据恢复公司。
    jasonyang9
        36
    jasonyang9  
       2018-12-21 11:56:34 +08:00
    虚拟机克隆一个再折腾啊
    itenyh
        37
    itenyh  
       2018-12-21 12:20:08 +08:00 via iPhone
    公司明知你是小白还让你上，公司应该要考虑到可能出现的后果，应当负主要责任。
    也许并不是什么重要数据，公司才让你玩。
    xzc19970719
        38
    xzc19970719  
       2018-12-21 12:23:15 +08:00 via Android
    😂关注一下。。因为我也不知道怎么缩分区
    asilin
        39
    asilin  
       2018-12-21 12:33:02 +08:00
    1. 缩小分区之前，应该先缩小文件系统；
    2. 扩大分区之后，再后扩大文件系统；

    看现在的情况，应该是操作系统根分区坏了，修复好的可能性很小，也非常的麻烦；
    但是 /home 分区是没有问题，这部分数据不会丢失；

    可以 livecd 进去后，重装系统，再把 /home 分区挂载上就可以了。
    oott123
        40
    oott123  
       2018-12-21 12:37:48 +08:00
    根据你更新的操作说明，我推测 home 分区能救。

    首先：进行所有后续操作之前，先给 vm 拍好快照。我提供的方法仅是一种可能，我和其它网友也没法对你的事情负任何责任，操作动手之前请先三思。

    然后想办法启动一个 rescuce system，例如楼上大家所说的 live cd。如果你是虚拟机，可以请管理虚拟机的人帮你挂载一个 ubuntu livecd iso 上去，最好再挂载一个额外的硬盘供你存放恢复出来的数据。

    挂载好之后，直接 mount 你的 home 分区（记得 -o ro 开只读），然后把数据拷贝出来。至此，home 数据恢复完毕。

    至于 root 分区？可能几乎没救，如果你想试试，可以对 root 分区跑 fsck，看看能剩下多少。
    lovefc
        41
    lovefc  
    OP
       2018-12-21 13:13:36 +08:00
    @oott123
    @asilin

    感谢大佬们费心，我现在正在找专业人员进行处理
    lovefc
        42
    lovefc  
    OP
       2018-12-21 13:18:35 +08:00
    @gamexg 谢谢您的意见
    lovefc
        43
    lovefc  
    OP
       2018-12-21 13:22:10 +08:00
    @P0P vm 上没有备份，也怪我太粗心了
    houzhimeng
        44
    houzhimeng  
       2018-12-21 13:45:30 +08:00
    我最讨厌逻辑卷了，所以帮不了你
    neilyoone
        45
    neilyoone  
       2018-12-21 13:48:18 +08:00
    哈哈，踩过这样 /home 分区空间不足的坑：
    前人留下的糟糕配置，手贱调整了下，命令少打了个符号 "-"，造成分区 inode 信息损坏无法修复，也同样是 lvm 分区。外面修复数据的也无法修复。
    lovefc
        46
    lovefc  
    OP
       2018-12-21 15:15:06 +08:00
    @neilyoone 你讲的我心都凉凉了
    Akiyu
        47
    Akiyu  
       2018-12-21 16:31:11 +08:00
    总结
    1. 不要减小分区
    2. 定时 lvcreate -s 备份

    顺便安慰一下 lz
    像服务器这种东西, 拿给你用的话, 一般都会防一些幺蛾子
    说不定有人已经写了 crontab 每天备份呢?
    a22124497
        48
    a22124497  
       2018-12-21 21:43:02 +08:00
    VM 上，不应试是直接扩容嘛，LVM 的扩容多方便，居然直接减分区
    msg7086
        49
    msg7086  
       2018-12-22 04:32:23 +08:00
    @Akiyu 为什么不要减小分区？氧化氢还能弄死人呢。

    @lovefc 不缩小文件系统就缩小分区相当于把人一刀腰斩。

    如果不 resize2fs home，那你数据还是全的。resize 完你的 root 就被覆盖上数据了。
    不要多纠结了，重装系统然后从备份里恢复吧。

    另外，下次记得不要用百度搜资料，一堆瞎瘠薄写的教程在那等着害人呢。
    Akiyu
        50
    Akiyu  
       2018-12-22 08:21:02 +08:00
    @msg7086
    嗯, 说错了
    lovefc
        51
    lovefc  
    OP
       2018-12-27 16:00:16 +08:00
    结贴了，我自己解决掉了，通过重新挂载。找回了数据。。T_T
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2613 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 10:59 · PVG 18:59 · LAX 02:59 · JFK 05:59
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.