渔人小径 · 唯逻辑不破
11月21日，北京第一场雪（南城是雨夹雪）；跟娃约好的晨跑泡汤了，于是打开FR24，随便找个大兴出发的航班跟一下。
看着航班上了航路B215，其整体起飞的航迹比较符合大兴的SID RNAV RWY 35R，所以猜测是35R起飞吧。但在经过AD655直到PEGSO点的高度都超过了4700米，因此猜测是ATC提前取消高度限制？
【注】AIP航图来源 – sinofsx
然后就沿着B215过太原，经吕梁过黄河，航向不变W43过延安，转向南走W47，直至LOVRA点。这条航路从大兴去往西南方向基本是主干线路，大兴去成都也同样走这里。
说到黄河，航路途经吕梁上空时，如果天气晴好，乘客舷窗上可以用手机（注意使用飞行模式）很清晰的拍摄。
完整阅读本篇»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物理机上执行如下命令 –
|
1 2 3 4 5 6 7 8 9 10 11 12 |
root@pve-test-pbs:~# proxmox-backup-client backup 121-root.pxar:/ --repository 192.168.1.122:test-store-01 Starting backup: host/pve-test-pbs/2020-10-13T03:06:41Z Client name: pve-test-pbs Starting backup protocol: Tue Oct 13 11:06:41 2020 Upload directory '/' to '192.168.1.122:test-store-01' as 121-root.pxar.didx 121-root.pxar: had to upload 1.67 GiB of 1.87 GiB in 23.20s, average speed 73.54 MiB/s). 121-root.pxar: backup was done incrementally, reused 208.00 MiB (10.9%) Uploaded backup catalog (1.00 MiB) Duration: 23.28s End Time: Tue Oct 13 11:07:04 2020 root@pve-test-pbs:~# |
其中 –
备份完成后，从PBS管理界面，可以看到备份信息。
更有意思的是，备份可以展开，甚至可以下载某一具体文件。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# root @ pbs-test in /mnt/datastore/test-store-01 [11:29:24] $ ll total 24K drwxr-xr-x 4 backup backup 4.0K Oct 13 11:06 host drwx------ 2 root root 16K Oct 12 15:29 lost+found drwxr-xr-x 3 backup backup 4.0K Oct 12 16:02 vm # root @ pbs-test in /mnt/datastore/test-store-01 [11:29:36] $ ll host/pve-test-pbs/2020-10-13T03:06:41Z total 40K -rw-r--r-- 1 backup backup 25K Oct 13 11:07 121-root.pxar.didx -rw-r--r-- 1 backup backup 4.2K Oct 13 11:07 catalog.pcat1.didx -rw-r--r-- 1 backup backup 399 Oct 13 11:07 index.json.blob |
那么如果从PVE上列出PBS的备份，从而检查内容和恢复呢？
完整阅读本篇»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声称的“去重、增量、加密、数据完整性以及压缩”的功能实现咯？
完整阅读本篇»Aerobatic flight @ Shanghai World Financial Center & Oriental Pearl
标配的特技机型，名字Extra 330LT，那种操控感（响应、跟手）是真实的爽快淋漓；除了爽以外，更重要的一点，偏真实感。这种真实不单纯体现在爬高后的失速，一次性大bank时会听到类似拉钢缆的声音，90° bank后下坠，超G的报警，以及操控动作时打在风挡和仪表板上的光照变化……一切都真实到让人欲罢不能。
Go! Silver go!
完整阅读本篇»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后画风大致是这样的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
➜ ~ top top - 22:26:04 up 2 days, 13:44, 3 users, load average: 0.96, 0.99, 0.93 Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie %Cpu(s): 8.4 us, 2.7 sy, 0.0 ni, 82.4 id, 6.3 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 926.1 total, 222.2 free, 171.1 used, 532.7 buff/cache MiB Swap: 100.0 total, 100.0 free, 0.0 used. 693.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 345 root 20 0 968804 21248 13064 S 37.3 2.2 1065:41 snapd 84 root 20 0 0 0 0 S 1.0 0.0 28:27.25 jbd2/mmcblk0p2- 15049 pi 20 0 10440 3096 2540 R 1.0 0.3 0:00.09 top 346 root 20 0 2968 2060 1564 S 0.7 0.2 2:17.19 dhcpcd 17101 root 0 -20 0 0 0 I 0.7 0.0 2:49.94 kworker/0:1H-mmc_complete 10 root 20 0 0 0 0 I 0.3 0.0 7:00.05 rcu_sched 18 root 0 -20 0 0 0 I 0.3 0.0 4:21.89 kworker/1:0H-kblockd 83 root 0 -20 0 0 0 I 0.3 0.0 4:24.37 kworker/2:1H-kblockd 412 root 20 0 31976 9496 8068 S 0.3 1.0 0:29.19 nmbd |
于是很想了解这货在干嘛，消耗这么多脑力，思考人生么？
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
➜ ~ sudo lsof -p 345 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME snapd 345 root cwd DIR 179,2 4096 2 / snapd 345 root rtd DIR 179,2 4096 2 / snapd 345 root txt REG 7,0 13421332 7147 /snap/core/9291/usr/lib/snapd/snapd snapd 345 root mem REG 179,2 1296004 2022 /lib/arm-linux-gnueabihf/libc-2.28.so snapd 345 root mem REG 179,2 130416 2085 /lib/arm-linux-gnueabihf/libpthread-2.28.so snapd 345 root mem REG 179,2 17708 10917 /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so snapd 345 root mem REG 179,2 138604 1945 /lib/arm-linux-gnueabihf/ld-2.28.so snapd 345 root 0r CHR 1,3 0t0 1028 /dev/null snapd 345 root 1u unix 0xf31a5a4c 0t0 14576 type=STREAM snapd 345 root 2u unix 0xf31a5a4c 0t0 14576 type=STREAM snapd 345 root 3u IPv4 152109 0t0 TCP 192.168.50.127:48604->api.snapcraft.io:https (ESTABLISHED) snapd 345 root 4u IPv4 233503 0t0 TCP 192.168.50.127:40786->api.snapcraft.io:https (ESTABLISHED) snapd 345 root 6u a_inode 0,11 0 5804 [eventpoll] snapd 345 root 7u unix 0x5b752603 0t0 14350 /run/snapd.socket type=STREAM snapd 345 root 8u unix 0xfebd686d 0t0 14353 /run/snapd-snap.socket type=STREAM snapd 345 root 9u REG 179,2 0 386387 /var/lib/snapd/snaps/core_9668.snap.partial snapd 345 root 12u netlink 0t0 18728 KOBJECT_UEVENT snapd 345 root 13r FIFO 0,10 0t0 18729 pipe snapd 345 root 14w FIFO 0,10 0t0 18729 pipe |
看起来是想回家拉点什么私货回来（api.snapcraft.io），但还是搞不懂，走io就走io，连续几天24小时一直吃那么多cpu是什么鬼？
完整阅读本篇»Powered by WordPress | 京ICP备17001541号-1 | 
京公网安备 11011502004657号
