使用PBS备份PVE物理机特定路径

2020-10-13 作者:

This post shows you how to use PBS (Proxmox Backup Server) to backup a specific directory (or mount point) of a PVE (Proxmox Virtual Environment) server, which is NOT exactly same thing in my mind – to backup a physical PVE machine and restore to be another new one (with all my personal settings in) though, but still somehow interesting and worth a try.

本文简介如何使用PBS(Proxmox Backup Server)进行PVE物理机备份。

本以为,这功能可以把pve物理机clone一份然后秒恢复成一台新物理机(类似硬盘dd但更简单)。但实际并非如此,该功能是把特定路径(比如根目录)下的文件整体打包备份(不含已挂载别的分区的路径);而恢复时也不是整分区恢复,而是按文件恢复,且文件已经存在时会报错。

虽然跟想的不太一样,至少这货有一点好处,简便易操作。相当于给PVE物理机磁盘打了个snapshot,而且PBS的管理界面可以把备份解开,只下载(恢复)其中某一个文件,有一定的实用价值。

现在看下备份过程,在PVE物理机上执行如下命令 –

其中 –

  • backup指备份操作。
  • 121-root.pxar是备份到具体的文件名,而pxar是pbs使用的备份文件格式。上一篇PBS初体验中提到了PBS中特殊的存储方式,这里也不例外,121-root.pxar文件名在pbs中也只是个索引文件,具体数据存储也是打散在.chunks下的65536个子目录中。
  • :/  指要备份root挂载点(之下比如/var挂载了别的分区,则不会被备份到)。
  • --repository  告诉备份命令,要备份到远端的PBS服务器。
  • 192.168.1.122:test-store-01  给出PBS服务器的具体IP(端口默认8007)和存储池名字。

备份完成后,从PBS管理界面,可以看到备份信息。

更有意思的是,备份可以展开,甚至可以下载某一具体文件。

那么如果从PVE上列出PBS的备份,从而检查内容和恢复呢?

完整阅读本篇»

Proxmox Backup Server上手初体验

2020-10-12 作者:

This is a basic test of PBS (Proxmox Backup Server) within only about 1 hour. So this literally means nothing but a bit of preliminary experience, which might be incorrect after some research in the near future, and should not be considered as a tutorial.

今天试了一下Proxmox Backup Server(以下简称PBS),国庆期间新鲜出炉的Beta 2,此处大致简单记录一下。

【注】体验时间不长,前后也就1小时多点儿。若有谬误敬请指出,可能很多东西还得读一下文档才能搞清楚。

 

首先,安装过程略去不提。因为PBS保持与PVE(Proxmox Virtual Environment)同样简洁的部署方式和安装速度。

装好后,可以把PBS当做外置存储直接挂载到PVE(单机或集群)上,并对单台vm直接进行备份,全程UI无需任何命令行操作。

而在PBS一端也提供相应的web UI(默认端口8007,区别于PVE的8006)对本地存储池进行管理,也可连接Remotes(不是指PVE,是指远端其他PBS)进行vm、lxc及其他PVE数据进行多端(比如云端+本地,又比如异地)备份的同步。

【注】:PBS需两块以上硬盘,其中一块独立系统盘,另1~n块为数据盘,从web UI可以全过程操作数据盘的分区表初始化、分区格式化以及挂载,支持ext4和zfs两种文件系统。

对PVE上vm 503(Ubuntu 18.04 LTS Server)进行备份,虽然web UI显示备份占用空间64GB(PVE对vm分配的磁盘大小),但实际占用PBS存储空间只有3.6GB,与PVE上的qcow2磁盘(稀疏文件)格式比较相似。

但深究之下,PBS的备份存储比较特别,不同于PVE上单个vm备份压缩包。PBS正经备份目录只有几个描述和索引文件,而实际数据存在一个名为.chunks的隐藏目录,之下有用4位16进制字符命名的,共计65536个子目录来存储经过分割的数据块。

所以是这种我不太理解的存储方式,提供了PBS声称的“去重、增量、加密、数据完整性以及压缩”的功能实现咯?

完整阅读本篇»

特技飞行 @ 陆家嘴开瓶器

2020-08-27 作者:

Aerobatic flight @ Shanghai World Financial Center & Oriental Pearl

标配的特技机型,名字Extra 330LT,那种操控感(响应、跟手)是真实的爽快淋漓;除了爽以外,更重要的一点,偏真实感。这种真实不单纯体现在爬高后的失速,一次性大bank时会听到类似拉钢缆的声音,90° bank后下坠,超G的报警,以及操控动作时打在风挡和仪表板上的光照变化……一切都真实到让人欲罢不能。

Go! Silver go!

完整阅读本篇»

Raspbian上snapd狂吃CPU问题

2020-07-22 作者:

To get rid of  snapd  on Raspbian/RaspberryPi OS Buster, since it eats lots of cpu power, especially on the old hardware, like a Pi 2B.

一台年迈的Pi 2B,运行着时时更新的Raspbian Buster,兢兢业业给娃做文件服务器,不亦乐乎。

一天apt dist-upgrade之后,就发现system load频繁升高,系统空载就能吃掉大致一个核的性能。top后画风大致是这样的。

于是很想了解这货在干嘛,消耗这么多脑力,思考人生么?

看起来是想回家拉点什么私货回来(api.snapcraft.io),但还是搞不懂,走io就走io,连续几天24小时一直吃那么多cpu是什么鬼?

完整阅读本篇»

强力!乳状积云+雷雨

2020-07-07 作者:

高考前日(2020-07-06)傍晚,迎来一场短时豪雨。
按父亲的话说,再干旱的年份,高考总要滴上几滴的,无他,老人言此乃龙王爷鼓励年轻人奋勇争先。何况今年本来雨水就足,这场不过1小时瓢泼大雨,算是给高考学子们示下的好兆头咯。

话说昨日晚霞长这样(小区群盗图):

让人不禁联想起《航空气象》书里的乳状积云的照片:

再看当时的首都机场METAR情况(按时间早→晚排列):

完整阅读本篇»

“小森林” 码工版

2020-06-28 作者:

明.陈全之《蓬窗日录》卷八:“春耕夏耨(nòu),敢辞涂足之勤;秋获冬藏,实切资身之望。”

日剧《小森林》,前后两部四集,全面的描绘出一个不甘挣扎于城市枯燥生活的妹子,返乡后独居,靠自己一双手打造返璞归真“小确幸”的图景,唯美、静心。本是2014/2015的片子,不知为何,去年突然火爆国内,还盖上“日版李子柒”的标签,颇觉给脑袋里整日萦绕“逃离北上广”的年轻人们一丝抚慰。

“农协开的小超市,冬雪中需步行一个半小时,而去临镇的大型城外超市购物,来回要一整天”,一句话下来,心凉半截;前可着村,但后不着店,换言之,一切靠自己了。

剧集展现给我们的,也确实如此:一日三餐,每餐结束之后,手头活计如果不是在准备下一餐,应该就是在准备下N餐(腌制发酵食品,或晾晒干制食品),日复一日,周而复始。另有国产美食剧集《一人食》好像也是在2014年上线的,并没有很火,我也没有看过,家里那口子倒是个不折不扣的美食爱好者。

洋洋洒洒说了这么多,跟码工又有几毛钱关系呢?码工嘛,又称“互联网从业者”,算是近年实体经济普遍乏力后,苦出身底层娃们为数不多的上升通道了。

所谓互联网大厂,自然有大厂的好处。流水线作业毕竟分工细,需求有人出,测试有人做,UI有人画,运维有人管,自己聚焦自己的一亩三分地;即使起新项目,研发主管还给脚手架工程做参考,说到底,搬砖就搬自己的砖,搬多少块结多少账,公平合理。要在大厂晋升,当然也是有讲究的。真材实料不可或缺,搬砖一路搬到CTO多半不可行;即使做技术主管,也得有点架构意识,当个“流水线线长”,知道不同目标需求下的技术组合和性能指标,关注外界趋势,跟合作项目组打太极,了解手底下那几个货适合搬什么砖,以及他们万一不干了,排队来搬砖的还有谁,等等。

言而总之,大厂工作如果不来点自黑,比拼个端午、中秋礼包设计,那真像极了城市生活两点一线,日子不停复制粘贴的感觉。作为移动互联网时代流水线工人,面对“弹性工作”、“996”等潜台词,再看看蒸蒸日上的业务,合同上不菲的现金和RSU,照旧叹一口气,进会议室继续抢项目撕B。

那你的意思是,码工也能回村自给自足,搞“一人码”?

也是,也不是。

全栈工程师不新鲜,算得上自给自足。至于要不要回村,您请自便,如果是农业创业,老板、市场、销售、PM、DevOps、运营、物流啥的您都一人扛了,咱也佩服;如若仅仅实现一人码,那大可不必,怎么也得考虑对接需求方要顺畅吧。

呃……废话太多,来点干货。

好吧,这篇围绕“一人码”的博文,其实来自于处理我“一人码”的一次线上故障。

完整阅读本篇»